使用boost :: asio :: ip :: tcp :: socket :: cancel（）和socket :: close（）

Question

If I use close and not cancel, there are some problems.

The close function can close the socket, and any outstanding asynchronous operations is stopped by returning boost::asio::error::operation_aborted error.

Why should I use cancel instead of close ?

I worry if some asynchronous operations is executing, the cancel could not cancel it, yes?

Like asio::ip::tcp::resolve::cancel , I try many times to cancel the resolve_handler after calling async_resolve , but resolve_handler always returns with no boost::asio::error::operation_aborted error.

I think resolve_handler is being executed?

Yes?

Answer 1

Cancel is useful if you want to stop pending operations without closing down the socket.

Note that the Boost documentation recommends using close for greater portability (from doc page):

... For portable cancellation, consider using one of the following alternatives:

• Disable asio's I/O completion port backend by defining BOOST_ASIO_DISABLE_IOCP.
• Use the close() function to simultaneously cancel the outstanding operations and close the socket.

Answer 2

cancel won't close the socket, so use cancel if you intend to continue using the socket object. In particular, if you have code in asynchronous handler methods that references the socket's member functions, you may not want to close the socket until you are guaranteed that your currently executing asynchronous handlers have completed.

cancel doesn't guarantee anything about currently executing asynchronous handlers, it only guarantees (per the boost documentation) that "This function causes all outstanding asynchronous connect, send and receive operations to finish immediately" in the case of the socket::cancel() call, or "This function forces the completion of any pending asynchronous operations on the host resolver" in the case of the resolver::cancel() call. This "completion" means that boost will call your asynchronous handler method, it has no jurisdiction to inject any cancellation logic into your asynchronous handler (not to mention it doesn't know about the handler's implementation to begin with).

I would suggest adding your own logic into your asynchronous handler method to handle the case where the socket/resolver/etc. is canceled. If you are calling the cancel method, then you likely have the ability to communicate this cancellation to the asynchronous handler method.