On Thu, Jul 26, 2018 at 4:23 AM, Cristian Morales Vega wrote:

By this definition of "completed" shouldn't my sample code be fine?

Actually, running the code under the Visual Studio debugger, I realize now that there are multiple bugs. First, there is the incorrect signature passed to async_completion as you noted. Second, you are using the wrong overload of post. Your code should read: boost::asio::post( this->get_executor(), boost::beast::bind_handler(std::move(init.completion_handler), ec)); The consequence of using the 1-argument version of `post` is that your completion handler will run on a system_executor rather than the executor associated with the I/O service of your object. This can be easily verified in the debugger: https://i.imgur.com/BsZYgHM.png And finally there is the original problem where there is no executor_work_guard for the io_context.

This is not supposed to be a composed operation.

You're right about that, and my apologies for the confusing terminology. I use "composed operation" to also refer to a particular style of implementation where a class is written as an invocable function object and is its own completion handler (disclaimer, untested code): template <class Handler> class composed_op { io_context& ioc_; Handler h_; executor_work_guard w_; public: template <class Deduced> composed_op (io_context& ioc, Deduced&& h) : ioc_ (ioc) : h_ (std::forward<Deduced>(h)) , w_ (ioc) { boost::asio::post(ioc_, std::move(*this)); } using allocator_type = boost::asio::associated_allocator_t<Handler>; allocator_type get_allocator() const noexcept { return (boost::asio::get_associated_allocator)(h_); } using executor_type = boost::asio::associated_executor_t; executor_type get_executor() const noexcept { return (boost::asio::get_associated_executor)(h_, ioc_.get_executor()); } void operator()() { h(); } }; I know, its a lot. Thanks

On Thu, Jul 26, 2018 at 5:33 AM, Bjorn Reese via Boost-users wrote:

On 07/25/18 19:12, Vinnie Falco via Boost-users wrote: post() is an asynchronous operation, so it takes care of that (see section 13.23.)

I'm certain that the executor_work_guard is needed, this guidance comes from Chris. The note in 13.23 is non-normative and probably misleading in this context. I'll raise the point with the editor.

On Thu, Jul 26, 2018 at 6:31 AM, Bjorn Reese via Boost-users wrote:

I was referring to 13.23 in its entirety, not just the non-normative note at the beginning. Specifically, look at paragraph 13.23/6.2.2.

I'm still certain that an executor_work_guard is needed. 13.23/6.2.2 specifies that `post` only constructs the work guard for the completion handler's associated executor. It says nothing about a work guard for the executor associated with the I/O object, see 13.2.7.8/2.1 and 13.2.7.10/1.1 You're right that `post` satisfies 13.2.7.10/1.2 Thanks

On Thu, Jul 26, 2018 at 7:23 AM, Bjorn Reese via Boost-users wrote:

The post operation is handed off to the executor (13.23/6.3) so I would assume that the definition of "outstanding work" in 14.2 rather than 13.2.7.10 applies.

Right, so we know that `post` will construct executor_work_guard for the executor associated with a completion handler. And we know that the asynchronous operation is then responsible for constructing the executor_work_guard for the executor associated with the I/O object (in this case it is an object of type io_context::executor_type). If the completion handler has no associated executor, for example if it is a lambda or a bind wrapper, then the executor of the I/O context will be used (assuming the 2-arg version of `post` is called, which is required for correctness), and everything will seem to work even without the second work guard. However, if the completion handler has an associated executor, then omitting the second work guard results in an io_context with no outstanding work. Therefore, io_context::run returns immediately, and the completion handler is not invoked. This is what I see in Visual Studio. Linux users may see a different result on account of some implementation differences. Stackful coroutines launched with `spawn` have an explicit `strand`, which means the associated executor is NOT the same as the executor for the I/O context upon which the strand was launched. Therefore, omitting the executor_work_guard from an asynchronous operation which only calls `post` will not meet the asynchronous requirements for the case where the completion handler is a stackful coroutine. If anything, this just highlights the complexity of [networking.ts]. Users will definitely be making these mistakes repeatedly, especially the one where the 1-arg version of `post` is called instead of the 2-arg version. Thanks

On Thu, Jul 26, 2018 at 6:03 PM, Gavin Lambert via Boost-users wrote:

This raises a concern that I've had for a while; if it's this hard to implement asynchronous operations correctly, I can't see it being very successful in practice. ... This means that everybody, including general application developers, needs to be able to easily write asynchronous methods, without having to worry about falling into these pitfalls. (It needs to be a "pit of success", not requiring several code reviews by experienced library developers in order to spot the mistakes.)

I feel you. But I do not see any obvious improvements or alternatives to the current design of [networking.ts], which provide the same or greater levels of expressive power and performance. There is nothing "easy" about writing concurrent asynchronous code in C++, which I believe is a consequence of having zero-cost abstractions. The following is an excerpt from a recent paper of mine: "From the author's experience and the visible cascade of problems with the example code in this paper, writing initiating functions and composed operations correctly requires a demanding amount of experience and skill. This is especially true when considering that such algorithms must also implicitly exhibit correct behavior in multi-threaded environments. This is accomplished by achieving a deep and thorough understanding of Asio or [networking.ts] and applying that understanding to code. The author and contributors to Boost.Beast have explored library solutions to provide some correct boilerplate and higher level idioms to users in order to make authoring composed operations easier to write. A little bit of progress has been made on this front, but comprehensive improvements have been elusive. We suspect that grand unifying solutions simply do not exist, and that the level of complexity is inherent to the domain." Regards

On Thu, 2 Aug 2018 at 17:25, james via Boost-users < boost-users@lists.boost.org> wrote:

On Thu, Aug 2, 2018 at 2:44 PM, Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:

...

On Thu, Jul 26, 2018 at 6:03 PM, Gavin Lambert via Boost-users wrote:

...

This raises a concern that I've had for a while; if it's this hard to implement asynchronous operations correctly, I can't see it being very successful in practice. ... This means that everybody, including general application developers, needs to be able to easily write asynchronous methods, without having to worry about falling into these pitfalls. (It needs to be a "pit of success", not requiring several code reviews by experienced library developers in order to spot the mistakes.)

I feel you. But I do not see any obvious improvements or alternatives to the current design of [networking.ts], which provide the same or greater levels of expressive power and performance. There is nothing "easy" about writing concurrent asynchronous code in C++, which I believe is a consequence of having zero-cost abstractions. The following is an excerpt from a recent paper of mine:

"From the author's experience and the visible cascade of problems with the example code in this paper, writing initiating functions and composed operations correctly requires a demanding amount of experience and skill. This is especially true when considering that such algorithms must also implicitly exhibit correct behavior in multi-threaded environments. This is accomplished by achieving a deep and thorough understanding of Asio or [networking.ts] and applying that understanding to code. The author and contributors to Boost.Beast have explored library solutions to provide some correct boilerplate and higher level idioms to users in order to make authoring composed operations easier to write. A little bit of progress has been made on this front, but comprehensive improvements have been elusive. We suspect that grand unifying solutions simply do not exist, and that the level of complexity is inherent to the domain."

Networking is complex? Not necessarily so. ASIO is confusing and over-engineered, and I bet there's a lot of identical boilerplate code out that has "this works, don't touch it" comments.

In my view, asio suffers from: a) incredibly terse documentation (it needs a lot more human 'chat' about 'why we do it this way', 'how we got here' and 'what this is actually trying to achieve') b) No documentation at all for writing your own services which execute handlers properly - it's easy to write services 'wrong' (i.e. they end up posting a call to a functor) but I've never managed to write a service which works correctly with asio::use_future or a coroutine - it's just too much work to unpick all the non-documented detail in Chris's incredible work! This is a terrible shame as in all other respects I consider ASIO to me a masterpiece.

Networking.TS has unfortunately tied itself to executors, there was no need for that.

To be fair, it's probably easier to use libuv and put up with the loss of type safety. At least you'll be able to set timeouts properly.

Sadly true until someone documents how to write a service properly. And I don't mean a trivial one as in the boost examples. A proper service which hands off work to a another thread and then marshals results back to the initiating object's executor.

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

On 08/02/18 17:24, james via Boost-users wrote:

Networking.TS has unfortunately tied itself to executors, there was no need for that.

Can you elaborate Are you talking about the split between io_context and executors?

To be fair, it's probably easier to use libuv and put up with the loss of type safety. At least you'll be able to set timeouts properly.

This is surprising observation, because I have the exact opposite experience. Can you elaborate? When I compare my Asio and libuv wrappers, the libuv timer code is more complex because the cancel operation needs to do a deferred deletion. The rest of the wrappers are roughly comparable in complexity (if we ignore all the type-casting needed by the libuv wrapper.)