And how would it know if the handler is a continuation?

Now you're right at the edge of my understanding. I've tried to follow this stuff through in the asio source code previously.

As I understand it, you can write your own handler objects, rather than than simply passing in a lambda or bind, which get notified either:
1. once on completion of the entire request, or
2. for every sub-operation of a compound operation such as async_read()

asio figures out which one you mean through some template jiggery-pokery (technical term) and your handler gets called the right number of times, on the right thread.

But frankly, this stuff has historically been so under-documented (for my simply mind) and written in a WORN (write-once, read-never) combination of macros and template specialisations that I gave up, and limited my ASIO services to simply invoking a handler function on the correct executor and letting the client take it from there.

I had hoped to take inspiration from the wonderful but IMHO incomplete AMY wrapper ( [mysql wrapped in an asio async wrapper]. But Cheng seems to have hit the same wall as me, and you can't handle an async_query with an asio::use_future, for example.
Hopefully the TS will clarify all this over time...

On 5 January 2018 at 16:55, Vinnie Falco via Boost-users <> wrote:
On Fri, Jan 5, 2018 at 7:53 AM, Richard Hodges via Boost-users
<> wrote:
> Perhaps defer does a post
> unless the handler is a continuation? I think that would make sense.

And how would it know if the handler is a continuation?

Boost-users mailing list