Re: [Boost-users] [release] Boost 1.67.0 Beta 1

Subject: Re: [Boost-users] [release] Boost 1.67.0 Beta 1
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-03-26 22:46:09

On 24/03/2018 02:51, Vinnie Falco wrote:
> A user discovered a defect in Beast. A recent change switched calls to
> boost::asio::post from the 2-argument version to the 1-argument
> version in order to simplify code and remove a redundant function
> call. Unfortunately this change was not safe, as it exposed a problem
> where Beast composed operations do not strictly adhere to the
> requirements of Networking.TS. Specifically that Beast composed
> operations should maintain the existence of an executor_work_guard for
> the I/O executor (not to be confused with the completion handler's
> associated executor).

Out of curiosity, do you have any link to discussion or documents that 
explain the reasoning and/or motivation for this?

I would have assumed that composed operations should not need the 
equivalent of io_service::work because work should be considered 
in-progress from the time that it is originally posted until such time 
as the completion handler *finishes* executing (thus if the completion 
handler posts additional work, there is no "gap").

That's certainly how Asio has historically worked.  You only need an 
explicit work guard if there are times when you have no outstanding work 
(eg. you let a completion handler exit without posting something new, or 
you run your io_service/io_context before you post your first operation).

Or is that last comment indicating that you're using two separate 
io_services, so you do have times where operations aren't pending on one 
or the other?