c++ - 以嵌套或递归方式(即在处理程序内)调用 asio io_service poll() 或 poll_one() 是否有效？

Question

以嵌套或递归方式(即从处理程序内)调用 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 }  } 

Answer 1

有效。

对于处理 io_service 的函数系列，run()是唯一有限制的:

The run() function must not be called from a thread that is currently calling one of run(), run_one(), poll() or poll_one() on the same io_service object.

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

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

---

对于 Windows I/O 完成端口，使用 GetQueuedCompletionStatus() 在为 io_service 服务的所有线程中执行多路分解.在较高级别，调用 GetQueuedCompletionStatus() 的线程的功能就好像它们是线程池的一部分，允许操作系统将工作分派(dispatch)给每个线程。由于没有单个线程负责将操作多路分解到其他线程，因此对 poll() 或 poll_one() 的嵌套调用不会影响其他线程的操作分派(dispatch)。 documentation状态:

Demultiplexing using I/O completion ports is performed in all threads that call io_service::run(), io_service::run_one(), io_service::poll() or io_service::poll_one().

---

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

Demultiplexing using [/dev/poll, epoll, kqueue, select] is performed in one of the threads that calls io_service::run(), io_service::run_one(), io_service::poll() or io_service::poll_one().

多路分解机制的实现略有不同，但在较高层次上:

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

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

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

当调用嵌套的poll() 或poll_one() 时，有必要将私有(private)队列复制到主队列中，作为要执行的操作将从主队列中消耗。此案例在 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()。}