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/