Re: [boost] Futures

Subject: Re: [boost] Futures
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-04 07:53:32

On Sunday, January 04, 2015 13:37:22 you wrote:
> On Sunday, January 04, 2015 12:46:26 Bjorn Reese wrote:
> > On 01/04/2015 11:25 AM, Thomas Heller wrote:
> > > What's the difference between async_result and a future? I am unable to
> > > find that in the ASIO documentation.
> > 
> > async_result is like a return type trait. In its generalized form in
> > Asio it supports callbacks, but has be specialized for futures and
> > coroutines. Other mechanisms can be added; for instance, Boost.Fiber
> > comes with an async_result specialization.
> > 
> > The important point with that design is that with async_result the
> > user of an asynchronous function gets to decide which mechanism to use.
> > 
> > Examples:
> >    // Callback
> >    socket.async_send(buffer, [] (error_code, size_t) { });
> >    
> >    // Future
> >    auto myfuture = socket.async_send(buffer, use_future);
> >    
> >    // Coroutine
> >    socket.async_send(buffer, yield);
> 
> Interesting. Let me try to explain what I am seeing in the future concept
> first and try to translate that async_result:
> For me, the concept behind futures is twofold, you have the future<T> on the
> *receiving* side which is, apart from the return type of the async
> operation, a completely type erased (as in type of asynchronous operation)
> handle to a future result. Things like promise, packaged_task or whatnot
> represent the *sending* side of the operation. That means, the only
> difference here is how the future result is being computed (locally,
> remotely or on a OpenCL device). This mechanism is completely hidden from
> the user, and currently a implementation detail of the various different
> libraries (with HPX being the exception here). And I believe this is a good
> thing. async_result seems to let the user decide how she would like to have
> the result produced, at least it looks like it ... after looking at the
> implementation it's "just" a trait from ASIO's async model to whichever you
> prefer. That could be done with different future islands just as well. The
> important part, for me, *how* the is being produced is not covered. In
> addition, it doesn't solve the problem of how to compose different
> future-like types or async concepts.

One more addition: The future concept with *how*, *where* and *when* tasks 
will get executed gets enhanced even further, and the executor can implement 
its own shared state, but the composability with other futures is still 
provided.

> 
> Cheers,
> Thomas
> 
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost