boost::asio::bind_executor() 行为，是有意的吗？

Question

我想在一个 io_context 中运行服务并在另一个 io_context 中执行业务逻辑。但首先我想了解更多有关重新调度行为的信息，因此我编写了一些实验代码。这是我的第一个版本（不使用 boost::asio::bind_executor()）

boost::asio::io_context context1;
boost::asio::io_context context2;

// for simplicity I use post here, it will be socket operation in real code
boost::asio::post(context1, [&context2]()
    { boost::asio::post(context2, []() { printf("job finished"); }); });

// notice I didn't run context1 here
context2.run();

context1 未运行，在本例中没有作业发布到 context2。所以 context2.run() 立即返回。当然，屏幕上没有打印任何内容。

然后这是使用 boost::asio::bind_executor() 的第二个版本

boost::asio::io_context context1;
boost::asio::io_context context2;

boost::asio::post(context1, boost::asio::bind_executor(context2, []()
    { printf("job finished"); }));

// notice I didn't run context1 here
context2.run();

在这种情况下，进程永远停留在 context2.run() 中，等待待处理的作业被交付。

因此手写的包装器代码和 boost::asio::bind_executor() 的行为不同。这是错误还是故意的？建议采用哪一种方式？

提前致谢

Answer 1

在第二个示例中，您将要执行的函数发布到 context1（未运行），但将完成处理程序绑定到 conext2\xe2\x80\x99s 执行程序。这意味着：

\n

\n
1. context1\xe2\x80\x99s异步操作处理器未执行该函数，因为 context1 未\xe2\x80\x99s 运行。
\n
2. context2\xe2\x80\x99s异步事件多路分离器等待完成事件队列上发生事件，因此阻止完成处理程序执行 printf。这是因为它必然会使事件或结果从队列中出列，并将其与完成处理程序关联起来。
\n

\n

在第一个示例中， context2\xe2\x80\x99s post 位于 context1\xe2\x80\x99s 完成处理程序内，并且由于 context1 未运行，因此 context1\xe2\x80\x99s异步操作处理器从未执行，并且因此，context1\xe2\x80\x99s 异步事件多路分离器无需等待。因此快速返回。

\n

增强文档

\n