Re: [boost] Futures vs async_result

Subject: Re: [boost] Futures vs async_result
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-27 08:42:11

On 27 Jul 2015 at 0:54, Michael Caisse wrote:

> > Hopefully this answer the question?
> 
> Thank you for the great explanation. You were saying async_result, I 
> repeated async_result, but I kept thinking completion handlers  :-/ 
> Fail on my part. Makes much more sense now.

C++ 1z coroutines should theoretically allow eventual replacement of 
ASIO as the reactor which watches kernel wait objects and when one 
signals, figures out what code should be run in response (i.e. 
completion handler).

However we're a long way away from that, and a lot depends on WG21's 
foresight on C++ 1z coroutines and Networking. I have noticed a 
substantial gap in consensus thinking therefore unfortunately, but 
the main protagonists are aware of the opportunities, even if they 
don't agree on a common vision.

> I would highly recommend putting this information somewhere in your 
> documentation. In some ways it is the motivation.

I'll see what I can do, but it's already looking quite challenging as 
simply an essay to write in itself.

I also don't particularly relish expending a full month on writing 
nothing but documentation :(, and it's currently looking this is what 
will be needed before we attempt a new AFIO review. Still, I guess I 
have the free time right now unusually.

> Future continuations are fine when the sequence from start to end 
> doesn't branch. I am cautious of their usefulness in the general case 
> still. It isn't uncommon to make choices in a completion handler to 
> queue different async actions with different completion handlers.

Lightweight future continuations have an extension to the Concurrency 
TS where you can add as many continuations as you like at any point 
of time, including within a continuation itself. As future 
continuations are really just delayed monadic continuations, you also 
get the full monadic programming power, so branching, whilst 
functionally specified, works as expected.

This makes them equally as capable as ASIO callback handlers and 
async_result, albeit not as efficient as Tongari pointed out. It's 
always going to cost at least 100 CPU cycles to add a continuation to 
a future due to the unavoidable synchronisation, and more like 
200-250 when you include the unavoidable malloc (used for type 
erasure). I still think the more succint programming and much easier 
to understand/maintain source code is worth the runtime cost.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/