[boost] [Asio] Commit-rollback on asynchronous operations - cancel / close may fail

Subject: [boost] [Asio] Commit-rollback on asynchronous operations - cancel / close may fail
From: Sorin Fetche (sorin.fetche_at_[hidden])
Date: 2013-08-14 21:01:30

Hi,

I noticed that functions for canceling asynchronous operations or closing
objects on which they are executed are documented as being possible to
fail. This is the case at least for the acceptor objects
(basic_socket_acceptor or ip::tcp::acceptor), socket objects (basic_socket
or ip::tcp::socket) and even timer objects (deadline_timer or steady_timer).

In this case what are the options for implementing commit-rollback for
asynchronous operations? By rollback I mean canceling a successfully
started first operation in case a second operation in the batch of
operations fails (as exemplified in the attached test code).

As described in [1] a rollback operation absolutely relies on no-throw
operations.

What is supposed to happen with the handler associated with the
asynchronous operation that failed to be canceled? Handlers, most often, at
least for non-trivial programs are carrying shared resources with them and,
if not called, may leave the application in a hanged state waiting for an
event that will never come.
I didn't find in the documentation any guarantees given regarding the
handlers associated with the async-operations that they can or cannot be
lost (that is never called). This of course, as long as io_service::run is
running or the control returns to it after an exception.

Also, as shown in [2] and as demonstrated by the attached test program, at
least for async_write, invoking the destructor of an object on top of which
asynchronous operations are being executed is not correct either and may
lead to undefined behavior (crash).

[1] Exception-Safety in Generic Components; section 6
http://www.boost.org/community/exception_safety.html

[2] BoostCon 2011: Thinking Asynchronously; slide 47
https://github.com/boostcon/2011_presentations/raw/master/mon/thinking_asynchronously.pdf

Thank you,
Sorin Fetche