On 5 January 2018 at 10:10, Richard Hodges via Boost-users < boost-users@lists.boost.org> wrote:

*post* used to cause the handler to be executed some time in the future on a thread associated with the executor. It was guaranteed not to happen immediately. *dispatch* used to: a. if called by a thread currently associated with the executor, cause the handler to happen now. b. otherwise behave as per post.

Has this really changed, or does the documentation have an error?

Although it is not supposed to be up to date, I think the description given in the documentation of the executor library that was proposed by the ASIO author is probably the best to understand the difference between these: https://github.com/chriskohlhoff/executors I don't know if there is a difference with the Network TS. A. Joël Lamotte

When I had a query regarding the newer standalone boost, I emailed Chris directly. He very helpfully replied promptly and fully. I have always felt that the documentation for ASIO is... terse. Perfect for Mekons, Terminator T2000's and Tron. Not so friendly for human beings. Every piece of information you need is there, exactly once, with not even one character more than is necessary to aid understanding. It took me a few readings for most of it to sink in. I'm still not sure how to code a service's handler invocation properly, so that it will work with futures, handler functions and co-routines (I can at least cause the handler to be posted to the correct io_context and ensure that the context stays 'running' for long enough for it to be executed. I would love to see an example of a fully-fledged asio service implementing, for example, the client side of an http-protocol-socket where the transport is running on a background thread. There are some books on the subject. But they cost, you know, money... On 5 January 2018 at 15:45, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:

...

Although it is not supposed to be up to date, I think the description given in the documentation of the executor library that was proposed by the ASIO author is probably the best to understand

On Fri, Jan 5, 2018 at 1:52 AM, Klaim - Joël Lamotte via Boost-users wrote: the

...

difference between these: https://github.com/chriskohlhoff/executors

It really would be nice if Chris Kohlhoff (author of Boost.Asio) could step forward and provide complete detail on how these functions are used, including a few examples such as usage in a composed operation implementation.

Thanks _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

I have a feeling that a better reference might be the latest TS document ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4711.pdf) since that's more likely to be rigorously scrutinised and maintained. defer and dispatch have this to say: " 1 [ Note: The function defer satisfies the requirements for an asynchronous operation (13.2.7), except for the requirement that the operation uses post if it completes immediately. — end note ]" which seems to suggest that defer and dispatch are allowed to invoke the completion handler immediately while post is not. Perhaps defer does a post unless the handler is a continuation? I think that would make sense. R On 5 January 2018 at 16:36, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:

On Fri, Jan 5, 2018 at 7:21 AM, Richard Hodges via Boost-users wrote:

...

When I had a query regarding the newer standalone boost, I emailed Chris directly. He very helpfully replied promptly and fully.

I emailed him too, several months ago, and this is what I got back:

post() -> handler_is_continuation() == false defer() -> handler_is_continuation() == true

...

Every piece of information you need is there, exactly once, with not even one character more than is necessary to aid understanding.

Yeah I know what you mean. It is quintessentially D.R.Y..

I'll note that Asio does not use defer() anywhere in its implementation. I have not found any code which demonstrates its use.

Thanks _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

On 5 January 2018 at 16:55, Vinnie Falco via Boost-users < boost-users@lists.boost.org> 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?

I think defer imply that the provided handler is a continuation. There are similar mechanisms proposed in the Executor proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0761r1.pdf (see page 6). Joël Lamotte

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 (https://github.com/liancheng/amy) [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 < boost-users@lists.boost.org> 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?

Thanks _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

Asio considered a handler to be a continuation if the function asio_handler_is_continuation returned `true` when passed a pointer to an instance of that handle

Right, unmaintainable jiggery-pokery

The new Asio does not use this mechanism. Instead, it requires that the caller use post() if the handler is not a continuation and defer() if it is.

Good! *much* more sensible! Thank you. On 5 January 2018 at 17:10, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:

...

...

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

As I understand it, you can write your own handler objects, rather than

On Fri, Jan 5, 2018 at 8:05 AM, Richard Hodges via Boost-users wrote: 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.

I don't think that is correct. Pre Net-TS, Asio considered a handler to be a continuation if the function asio_handler_is_continuation returned `true` when passed a pointer to an instance of that handler type. The new Asio does not use this mechanism. Instead, it requires that the caller use post() if the handler is not a continuation and defer() if it is. So the caller informs the implementation whether or not the handler is a continuation, just like before but by invoking the correct function.

However, it is not clear how to accomplish that. Which is why an example would be helpful.

Thanks _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users