以嵌套或递归方式（即在处理程序中）调用 asio io_service poll() 或 poll_one() 是否有效？答案

【问题标题】：Is calling asio io_service poll() or poll_one() in a nested or recursive fashion (ie. within a handler) valid?以嵌套或递归方式（即在处理程序中）调用 asio io_service poll() 或 poll_one() 是否有效？
【发布时间】：2015-02-21 22:18:58
【问题描述】：

以嵌套或递归方式（即从处理程序中）调用 asio::io_service::poll() 或 poll_one() 是否有效？

一个非常基本的测试似乎暗示这可行（我只在一个平台上完成了测试）但我想确保从处理程序中再次调用 poll() 被认为是有效的行为。

我在 asio 文档中找不到任何相关信息，所以我希望对 asio 内部工作有更多经验的人可以通过解释或参考来验证这一点。

基本测试：

struct NestedHandler
{
    NestedHandler(std::string name, asio::io_service * service) :
        name(name),
        service(service)
    {
        // empty
    }

    void operator()()
    {
        std::cout << " { ";
        std::cout << name;

        std::cout << " ...calling poll again... ";
        service->poll();
        std::cout << " } ";

    }

    std::string name;
    asio::io_service * service;
};

struct DefaultHandler
{
    DefaultHandler(std::string name) :
        name(name)
    {
        // empty
    }

    void operator()()
    {
        std::cout << " { ";
        std::cout << name;
        std::cout << " } ";
    }

    std::string name;
};

int main()
{
    asio::io_service service;
    service.post(NestedHandler("N",&service));
    service.post(DefaultHandler("A"));
    service.post(DefaultHandler("B"));
    service.post(DefaultHandler("C"));
    service.post(DefaultHandler("D"));

    std::cout << "asio poll" << std::endl;
    service.poll();

    return 0;
}

// Output:
asio poll
 { N ...calling poll again...  { A }  { B }  { C }  { D }  }

【问题讨论】：

虽然它应该是安全的（只有run() 有限制），但它的用法对我来说有点尴尬。有这个用例吗？
@TannerSansbury 你认为调度有影响吗？
@sehe 应该不会影响线程级调度。在某些情况下，它可以改变调用处理程序的顺序。

标签： c++ boost-asio

【解决方案1】：

有效。

对于处理io_service 的函数族，run() 是唯一有限制的函数：

不得从当前调用同一io_service 对象上的run()、run_one()、poll() 或poll_one() 之一的线程调用run() 函数。

但是，我倾向于认为文档也应该包含与 run_one() 相同的注释，因为嵌套调用可能导致它在以下任一情况下无限期阻塞^[1] ：

io_service 中唯一的工作是当前正在执行的处理程序
对于非 I/O 完成端口实现，唯一的工作是从当前处理程序中发布的，io_service 有一个并发提示 1

对于 Windows I/O 完成端口，使用GetQueuedCompletionStatus() 在为io_service 服务的所有线程中执行多路分离。在高层次上，调用GetQueuedCompletionStatus() 的线程就像它们是线程池的一部分一样，允许操作系统将工作分派给每个线程。由于没有单个线程负责将操作解复用到其他线程，因此对poll() 或poll_one() 的嵌套调用不会影响其他线程的操作分派。 documentation 声明：

在调用io_service::run()、io_service::run_one()、io_service::poll() 或io_service::poll_one() 的所有线程中执行使用I/O 完成端口的解复用。

对于所有其他多路分离机制系统，服务io_service 的单线程用于多路分离I/O 操作。确切的解复用机制可以在Platform-Specific Implementation Notes中找到：

在调用io_service::run()、io_service::run_one()、io_service::poll() 或io_service::poll_one().

多路分离机制的实现略有不同，但在高层次上：

io_service 有一个主队列，线程从中消耗准备运行的操作来执行
处理io_service 的每个调用都会在堆栈上创建一个专用队列，用于以无锁方式管理操作
最终会与主队列同步，获取锁并将私有队列操作复制到主队列中，通知其他线程，并允许它们从主队列中消费。

当io_service 是constructed 时，可能会提供一个并发提示，建议实现应该允许多少线程并发运行。当为非 I/O 完成端口实现提供1 的并发提示时，它们被优化为尽可能使用私有队列并延迟与主队列的同步。例如，当通过post() 发布处理程序时：

如果从处理程序外部调用，则io_service 保证线程安全，因此它会在将处理程序入队之前锁定主队列。
如果从处理程序中调用，则发布的处理程序将排入专用队列，延迟与主队列的同步直到需要。

当调用嵌套的poll() 或poll_one() 时，有必要将私有队列复制到主队列中，因为要执行的操作将从主队列中消耗。这种情况在implementation:

// We want to support nested calls to poll() and poll_one(), so any handlers
// that are already on a thread-private queue need to be put on to the main
// queue now.
if (one_thread_)
  if (thread_info* outer_thread_info = ctx.next_by_key())
    op_queue_.push(outer_thread_info->private_op_queue);

如果没有提供并发提示或提供除1 以外的任何值，则每次发布的处理程序都会同步到主队列中。由于不需要复制私有队列，嵌套的poll() 和poll_one() 调用将正常运行。

^{1.在networking-ts draft 中，注意不能从当前正在调用run() 的线程调用run_one()。}

【讨论】：

【解决方案2】：

在嵌套中调用 asio::io_service::poll() 或 poll_one() 或递归方式（即在处理程序中）有效吗？

从语法上讲，这是有效的。但是，它不好，因为在你应该运行 poll() 的每个处理程序中。此外，您的堆栈跟踪会变得非常大，您可能会遇到堆栈的大问题。

【讨论】：