śr., 29 gru 2021 o 15:26 Richard Hodges via Boost <boost@lists.boost.org> napisał(a):
<snip>
Thank you for the quick reply.
So, my question is: does ASIO give a guarantee that it destroys the
completion handler after the preceding operations have finished?
Asio will perform the following operations when about to invoke a completion handler:
- extract the handler from its surrounding async operation via std::move (assuming C++11 or better, otherwise it copies it). - destroy/deallocate any dynamic state in the async operation. - invoke the handler. - destroy the handler.
This assumes that the completion handler is invoked prior to the destruction of the execution context with which it is associated (the normal case).
Yes.
In the corner case of the execution context being destroyed, all outstanding async operations (which would include pending completion handlers) are destroyed.
So, I am not sure how many corner cases there are. One would be to destroy the execution context (like io_context). I understand that requesting a cancellation of an asynchronous operation is also a kind of special case: we do not expect the completion handler to be invoked. (Am I right?) I imagine that in order to provide the cancellation guarantee as expressed in https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/overview/core/canc... the framework still needs to execute some instructions. These final cleanup instructions might still require resources that the user provided (like the socket). The implementation might first execute these cleanup instructions and then destroy the completion handler, or do the opposite: first destroy the completion handler and then call the cleanup instructions. The resource handling strategy with the unique_ptr in the completion handler will work correctly in the first case, but not in the second. So, I would need an additional guarantee that says that the asynchronous operation performs no logic (other than the call to destructor) after destroying the completion handler -- even in the event of cancellation. Or maybe the resource-handling strategy in my example is not supported? Regards, &rzej;
Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost