Re: [boost] Futures

Subject: Re: [boost] Futures
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-01-16 00:07:36

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.