Using boost::asio::ip::tcp::socket::cancel() and socket::close()
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_abort开发者_如何学编程ed
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?
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.
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.
精彩评论