Re: [boost] Futures

Subject: Re: [boost] Futures
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-07 21:21:13

Le 08/01/15 02:36, Hartmut Kaiser a écrit :
>> Le 06/01/15 20:22, Vicente J. Botet Escriba a écrit :
>>> Le 06/01/15 11:23, Niall Douglas a écrit :
>>>> On 5 Jan 2015 at 22:41, Vicente J. Botet Escriba wrote:
>>>>
>>>>>> 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.
>>>> I would *far* prefer a notify_when_ready(callable), not least because
>>>> condition_variables are lost wakeup prone.
>> After some more thoughts, the callable interface is more open.
>>
>> The condition_variable interface could be something like
>>
>> // Return an unlocked LockableFutureHandle able to tell if the Future is
>> ready once the lock has been locked.
>> LockableFutureHandle Future::notify_when_ready(condition_variable&);
>>
>> <snip>
>>
>> template <class Callable>
>> voidFuture::when_ready(Callable&&);
>>
>> <snip>
>>
>>
>> voidFuture::notify_when_ready(LockableConditionVariable<std::size_t>&);
>>
>> <snip>
> Whatever you do, I'd suggest not to tie the API to any of the kernel-based
> synchronization objects.
>
>
Is a condition_variable a kernel synchronization object in HPX?

Best,
Vicente