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