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