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/