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. It is much easier to store a condition_variable than a Callable. In addition it ensures that the future value provider will not block until the callback finish and makes the user code thread safe, as the code is executed on the thread of its choice. But then you're effectively making futures into ASIO async_result.
I'm not a fan of async_result, as the way the function is used depends on a specific parameter. IMO, we need different functions when the user must follows a different protocol. Best, Vicente