0

我正在尝试用超时实现 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);
}

    HandleConnect()甚至可以在另一个线程中完成async_wait()（不太可能但可能）。我必须strand包装Start(),HandleConnect()和HandleTimeout()吗？

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

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

4

1 回答 1

1

  1. 如果要防止它们在不同线程中并行执行，则应使用 strand 包装每个处理程序。我猜一些完成处理程序会访问socket_或计时器，所以你肯定也必须Start()用一个链包裹。io_service但是使用 io_service-per-CPU 模型（即基于池的应用程序）不是更简单吗？恕我直言，你的头痛会少得多。

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

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

于 2012-11-21T16:39:42.757 回答