Re: [ASIO] Completion handler lifetime guarantees

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2021-12-29 15:04:42

śr., 29 gru 2021 o 15:26 Richard Hodges via Boost <boost_at_[hidden]>
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/cancellation.html
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
>