Re: [Boost-users] ASIO: Writing Composed Operations

Subject: Re: [Boost-users] ASIO: Writing Composed Operations
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-12-07 00:58:10

On 7/12/2018 12:59, Damian Jarek wrote:
> Here's an example of what might happen if a composed operation doesn't 
> maintain work guards properly:
> https://wandbox.org/permlink/aqsGDNJWTmFd7PdC

Why use conditional logic and extra storage in operator() when the 
compiler can do it for you?
   https://wandbox.org/permlink/HzOlDt8S6txfLNB6

> Without the work_guard the coroutine never completes. If you add the 
> work_guard, everything works correctly.

I can see it happening in your example, but I still don't really grok 
why this occurs.

Isn't the point of composed operations to ensure that they use the same 
executor for all handlers?  So it's the same executor as the underlying 
timer.  When it's in a wait operation, the timer should be taking care 
of it.  And while in the direct call context of operator() then the 
executor itself should know there is work in progress.

So the only time where the work_guard should be having any effect is 
either if async_foo itself yields (which it does, but only after 
creating the op and making a call to async_wait, so that should keep it 
alive) or if the call to handler_ yields somewhere else (which it doesn't).

(handler_() might internally post and yield rather than executing 
synchronously, especially cross-context, but in that case its executor 
should know that it's doing something.)

So what am I missing?

(I guess one of the things that I might be struggling with is that in Ye 
Olde Asio, as long as you always had an async_* in flight at all times 
then you never needed any io_service::work.  Usually that was easy 
because you typically have a listen or read in flight.)