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
Le 06/01/15 11:23, Niall Douglas a écrit : 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