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?