async_connect(）超时，多个线程执行io_service.run(）

async_connect() timeout with multiple threads performing io_service.run()

本文关键字：执行 io service run 线程 connect 超时 async      更新时间：2023-10-16

我正在尝试实现带有超时的async_connect()。

async_connect_with_timeout(socket_type & s,
std::function<void(BoostAndCustomError const & error)> const & connect_handler,
time_type timeout);

当操作完成时，调用connect_handler(error)，error指示操作结果(包括超时)。

我希望使用超时示例1.51中的代码。最大的区别是，我使用多个工作线程来执行io_service.run().

为了使示例代码保持工作状态，需要进行哪些更改？

我的问题是：

  1. 调用时：

    Start() {
socket_.async_connect(Handleconnect);
dealine_.async_wait(HandleTimeout);
}

    CCD_ 3甚至可以在CCD_ 4之前在另一个线程中完成(不太可能但可能)。我必须用strand包装Start()、HandleConnect()和HandleTimeout()吗？

  2. 如果首先调用HandleConnect()而没有错误，但由于HandleTimeout()"已在不久的将来排队等待调用"而导致deadline_timer.cancel()或deadline_timer.expires_from_now()失败，该怎么办？看起来示例代码可以让HandleTimeout()关闭套接字。这种行为(在我们愉快地开始连接后的一些操作后，计时器关闭连接)很容易导致严重的头痛。

  3. 如果先调用HandleTimeout()和socket.close()怎么办。HandlerConnect()是否可能已经"排队"而没有错误？文档中写道："任何异步发送、接收或连接操作都将立即取消，并将以boost::asio::error::operation_aborted错误完成"。"立即"在多线程环境中是什么意思？

  1. 如果您想防止它们在不同的线程中并行执行，则应该用strand包装每个处理程序。我想有些完成处理程序会访问socket_或计时器，所以您肯定也必须用一条链来包装Start()。但是，使用io_service-per-CPU模型，也就是说，将应用程序建立在io_service池上，不是更简单吗？IMHO，你的头痛会减轻很多。

  2. 是的，这是可能的。为什么会头疼？套接字由于"错误超时"而关闭，并且您启动重新连接(或其他)过程，就像它由于网络故障而关闭一样。

  3. 是的，这也是可能的，但同样，这不会给正确设计的程序带来任何问题：如果在HandleConnect中，你试图对一个闭合的套接字发出一些操作，你会得到适当的错误。无论如何，当您尝试发送/接收数据时，您并不真正知道当前套接字/网络状态。

相关文章：