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(LockableConditionVariablestd::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