On Fri, 9 Nov 2018 at 11:38, Damian Jarek via Boost-users <boost-users@lists.boost.org> wrote:
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).
Don't really know why if they are equal the executor_work_guard is not needed (I have some suspicious, but they break if multiple threads use the same io_context). But I see that in the case of echo_op they can potentially be different and so the executor_work_guard is there, fine.
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.
I guess that's my question. Why only "primitive" async operation need the 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.
I guess the example is fine no matter if the proposal is accepted or not since it uses `decltype(std::declval<AsyncStream&>().get_executor()`, right? PS: Keep in mind that I had quite clear why io_service::work up to Boost.Asio 1.65 was needed. Once Executors entered in the equation I got quite lost about how the executor_work_guard relates to them. Thanks!