当 I/O 对象已经有执行器时，为什么还需要 `net::dispatch`？

我正在从这个例子中学习 Boost.Beast 和 Boost.Asiolibs/beast/example/http/server/async-ssl/http_server_async_ssl.cpp - 1.77.0.

据我所知，I/O 对象上发生的所有 I/O 操作都发生在该对象的 I/O 执行上下文中。异步操作将在同一个线程中runI/O 上下文，因为它们都被（间接）调用runI/O 上下文。

在此示例中（请参阅上面的链接），当建立连接时，接受器为新连接分配专用链：

    do_accept()
    {
        // The new connection gets its own strand
        acceptor_.async_accept(
            net::make_strand(ioc_),
            beast::bind_front_handler(
                &listener::on_accept,
                shared_from_this()));
    }

这是否意味着新连接上发生的所有 I/O 操作都发生在链中？如果是这样，为什么示例使用net::dispatch在调用时再次指定链async_read?

    // Start the asynchronous operation
    void
    run()
    {
        // We need to be executing within a strand to perform async operations
        // on the I/O objects in this session. Although not strictly necessary
        // for single-threaded contexts, this example code is written to be
        // thread-safe by default.
        net::dispatch(
            stream_.get_executor(),
            beast::bind_front_handler(
                &session::on_run,
                shared_from_this()));
    }

如果我们只调用有什么区别async_read直接不经过net::dispatch？谢谢。 :)

这是否意味着新连接上发生的所有 I/O 操作都发生在链中？

这意味着接受的套接字获得引用该链的执行器的副本。这does意味着从该服务对象发起的所有异步操作都将默认情况下 （！）调用该链上的完成处理程序。但是，这不适用于任何其他操作，例如启动功能（例如s.async_read_some）本身。

因此，为了确保所有操作都发生在链上，您必须确保任何启动都发生在同一链上。在许多情况下，这将是自动的，因为许多启动发生在前一个操作的完成中 - 因此已经在链上 - 但不是第一个操作，如您所见。

（可以说，在新链的开始时，因此当刚刚创建 IO 对象并且链是该 IO 对象私有时，可以从任何线程安全地进行第一次启动，逻辑上成为链的一部分。可以将其视为链本身的分叉点（“诞生”）。这是因为没有任何操作可以进行，也没有其他线程可以保存对它的引用。）