boost::asio::tcp::socket 关闭并取消而不调用处理程序答案

【问题标题】：boost::asio::tcp::socket Close and cancel without handlers being calledboost::asio::tcp::socket 关闭并取消而不调用处理程序
【发布时间】：2012-05-24 13:03:32
【问题描述】：

我正在使用 boost 的 asio 库编写服务器。服务器使用一组 Connection 对象（围绕 boost::asio::tcp::socket 的包装类）处理许多并发连接。在 Connection 类中，使用 socket.async_read_some(...) 不断地读取套接字，并且每当使用新数据调用读取处理程序时，都会立即再次调用 socket.async_read_some() 以读取更多数据。

现在，服务器可能出于某种原因决定断开客户端，所以很自然的做法是调用 connection.close()，然后调用 socket.close()，这将导致所有挂起的异步操作取消。这会导致使用 boost::asio::error::operation_aborted 调用读取处理程序（绑定到类 Connection 中的方法）。而我的问题是：我不希望这种情况发生。

在 socket.close() 之后，我想销毁套接字和连接，然后从服务器的活动客户端列表中删除它的指针。然而，读取处理程序直到 io_service.run() 的下一次迭代才会被调用，这意味着我不能立即销毁套接字或我传递给 socket.async_read_some() 的读取处理程序，直到处理程序被调用错误。所以我必须以某种方式延迟这些对象的销毁；这很烦人。

有没有安全的方法

取消挂起的异步操作没有任何要调用的处理程序，所以我可以在 socket.close() 之后立即安全地销毁套接字，或者
安全地知道何时不能调用更多的处理程序

还是我完全错误地处理了这个问题？

【问题讨论】：

标签： c++ boost boost-asio

【解决方案1】：

当 async.operation 完成时 - 无论是成功还是出错 - 它的完成处理程序都会被调用。这是重要的保证，我认为尝试“破解”这种行为并不是一个好主意。您在用例中遇到的问题通常通过使用 shared_ptr (shared_from_this idiom) 来解决：将shared_ptr<Connection> 绑定到处理程序，当您遇到 operation_aborted（或其他错误）时不要发出另一个 async_read，这样当所有处理程序完成后，Connection 对象连同其套接字一起被销毁。

【讨论】：

这听起来很不错。我肯定没有使用足够的shared_ptr，甚至不知道enable_shared_from_this。我曾经这样做：“socket.async_connect(endpoint, boost::bind(&Connection::done_connect, this, _1))”，所以现在我只需在绑定调用中添加一个额外的“shared_from_this()”并更新即使在处理程序中甚至不会使用实际的 shared_ptr 的附加 shared_ptr 的方法签名？ IE。 shared_ptr 只是为了保证对象仍然存在。听起来对吗？
至少我是这样实现的，现在效果很好。非常感谢！
@jlh，说 shared_ptr“不会在处理程序中使用”并不完全正确。如果将成员函数绑定到 shared_ptr，它会存储在绑定器（使用 bind() 创建的函子）中，并在函子调用时取消引用。因此，指针的生命周期与函子的生命周期一样长。
我想我最初并没有按照您的想法实现它，因为我将 shared_ptr 绑定到 addition 中的回调以绑定“this”。（见我的第一条评论）所以 shared_ptr 确实从未使用过（除了隐式使用保持对象活动）。我现在修复了它，所以调用现在看起来像“socket.async_connect(endpoint, boost::bind(&Connection::done_connect, shared_from_this(), _1))”。这可能是您的意思，现在确实 shared_ptr 被取消引用以调用该方法。再次感谢！