c++ - boost ASIO : do we need to keep using async_read and write inside a function called from async_read?

Question

我一直在努力理解 boost 的 http server 3 example 中的逻辑.此示例中的请求在 connection.cpp 中的 start() 方法中读取，该方法调用:

socket_.async_read_some(boost::asio::buffer(buffer_),
      strand_.wrap(
        boost::bind(&connection::handle_read, shared_from_this(),
          boost::asio::placeholders::error,
          boost::asio::placeholders::bytes_transferred)));

注意async_read_some方法是documented to return immediately .然后在读取处理程序 (connection::handle_read()) 中，如果 parse 返回 boost::indeterminate，我们可能会再次调用 async_read_some。这比 socket_.read_some(buffer) 有什么好处，因为我们已经知道我们在一个单独的线程中工作。我问的原因是我想稍微更改消息解析以按需调用 read_some，但我想到的方法不适用于异步读取。

还有一个相关的问题:

之间有什么区别吗？

async_read_some()

和

boost::thread th([](){ ret = read_some(); handle_read(ret) });?

Answer 1

Boost.Asio 的 HTTP Server 3示例的编码方式使其对线程池的大小保持不可知。因此，无法保证工作将在单独的线程中完成。然而，不可知论的好处是它可以随着更多的连接更好地扩展。例如，考虑 C10K problem检查同时连接的 10000 个客户端。对于 10000 个客户端，同步解决方案可能会遇到各种性能问题或资源限制。此外，异步特性有助于将程序与网络中的行为变化隔离开来。例如，考虑一个具有 3 个客户端和 2 个线程的同步程序，但由于网络噪声的增加，其中 2 个客户端具有高延迟。如果两个线程都被阻塞以等待来自其他客户端的数据，则可能会无意中影响第三个客户端。

如果连接数量少且有限，每个连接由一个线程提供服务，那么同步服务器和异步服务器之间的性能差异可能很小。如果可能，通常建议避免混合使用异步和同步编程，因为它可以将复杂的解决方案变成一个复杂的解决方案。此外，大多数同步算法都可以异步编写。

异步操作和同步操作(即使是在专用线程中运行的操作)之间有两个主要区别:

• 线程安全。如 documentation 中所述:

  In general, it is safe to make concurrent use of distinct objects, but unsafe to make concurrent use of a single object.

  因此，当同步操作正在进行时，无法安全地启动异步和同步操作，即使该操作是在其自己的线程中调用的。这在半双工协议(protocol)中可能是最小的，但在全双工协议(protocol)中应该考虑。

• 能够取消操作。如 this 中所述回答，同步操作不能通过Boost.Asio提供的cancel()成员函数取消。相反，应用程序可能需要使用较低级别的机制，例如信号。