The executor_work_guard is required for situations in which the IoExecutor (Executor associated with an IoObject) has different identity (or type) than the Executor associated with the CompletionHandler (e.g. when used with asio::use_future_t). Since this is not a "primitive" async operation (that calls directly into the OS and manages operation suspension), we don't need to maintain an executor_work_guard for the CompletionHandler's executor. Currently, the IoExecutor is always io_context::executor_type, however there is a proposal (https://wg21.link/p1322r0) to enable users to provide custom Executors to IoObjects.

On Fri, Nov 9, 2018 at 11:00 AM Cristian Morales Vega via Boost-users <boost-users@lists.boost.org> wrote:
Hi,

I was looking at
https://www.boost.org/doc/libs/develop/libs/beast/doc/html/beast/using_io/writing_composed_operations.html
and came up with a question I can't answer: In
https://github.com/boostorg/beast/blob/develop/example/echo-op/echo_op.cpp#L95
why does it use the AsyncStream associated executor without even
looking at the potentially different (right?) Handler associated
executor?

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