On 4/01/2015 19:52, Niall Douglas wrote:
On 3 Jan 2015 at 7:15, Hartmut Kaiser wrote:
First of all, I fully support Thomas here. Futures (and the extensions proposed in the 'Concurrency TS') are a wonderful concept allowing asynchronous computation. Those go beyond 'classical' futures, which just represent a result which has not computed yet. These futures allow for continuation style coding as you can attach continuations and compose new futures based on logical operations on others.
They are also severely limited and limiting:
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.
Is there somewhere I can read up some more on this issue? Perhaps I have not put enough thought into it, but it seems like it should be trivial to create a wrapper to convert a std::future into a boost::future or the reverse. (It's slightly less trivial if you want to use a mixture of futures and shared_futures, but it should still be manageable.) Of course there are likely to be some performance costs to doing so, so it's not something you want to be doing in tight loops, but then I'm not convinced async in general is something you should be doing in tight loops. If it's only happening at the intersection point between libraries then it ought to be ok, although of course it depends on how much overlap is required by the application.