Re: [boost] Futures

Subject: Re: [boost] Futures
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-05 16:41:53

Le 05/01/15 12:01, Niall Douglas a écrit :
> On 4 Jan 2015 at 9:52, Hartmut Kaiser wrote:
>
>>> 1. They tie your code into "future islands" which are fundamentally
>>> incommensurate with all code which doesn't use the same future as
>>> your code. Try mixing code using boost::future and std::future for
>>> example, it's a nightmare of too easy to be racy and unmaintainable
>>> mess code. If Compute provided a boost::compute::future, it would yet
>>> another new future island, and I'm not sure that's wise design.
>> The easiest way to deal with this is to introduce a Future concept and
>> implement everything in terms of it. A solid set of traits/concepts-lite
>> should cover that.
> I don't think it's that easy because really it comes down to
> commonality of kernel wait object, or rather, whether one has access
> to the true underlying kernel wait object or not.
>
> For example, right now can boost::wait_all() ever consume
> std::futures? I suspect not because the HANDLE on Windows or the
> futex on Linux is rather hard to get at.
The current implementation doesn't accept std::futures, but there is no 
reason it can not accept other futures. All what is needed is the 
Future::wait() interface.

wait_for_any is different. The Boost thread implementation uses a list 
of condition_variable to notify when a the future becomes ready. Having 
a generic future<T>::notify_when_ready(condition_variable) will surely help.

Best,
Vicente