Hi Stian,

Some thoughts from an ASIO veteran and fan:

> - it's an all or nothing thing, i.e., it can't be used to cancel individual I/O requests


It is not valid to have more than one outstanding async read on an asio io object at a time*. cancel() will cancel the current async operation that is in progress on that object if there is one.

You have to remember that notifications come through the io_service and therefore “happen” for the client later than they actually “happened” in reality. If you want to correlate every completion handler invocation with every read call, then you might want to consider assigning an “invocation id” to each read operation and passing that to the closure (handler).

* clarification: deadline_timers may have more than one outstanding wait, and an io object may have an an outstanding read and write at the same time.

> it doesn't work on completed requests

Because the handler has already been passed to the io_service for invocation. From the socket’s point of view, you’ve been notified. Sending a cancel before the execution of the handler can only meaningfully result in a NOP because it’s a crossing case. Think of cancel() as meaning, “please cancel the last request if it’s not already completed."
 
> EVEN THOUGH the io service has a list of outstanding requests (waiting for completion) and pending (completed) handlers

Anything posted to the io_service will happen. It’s a done deal. The io_service is (amongst other things) a multi-producer, multi-consumer queue with some clever thread marshalling. This is important. Handlers often hold lifetime-extending shared-pointers to the source of their invocations. The handler’s invocation is where the resource can be optionally released.

> I could also just call stop() on the io_service…

This would indicate a design error. Think of the io_service as “the global main loop” of your program. When writing a windows or OSX program, no-one “stops” the windows message loop. Messages have been posted. They must be dealt with. This is the nature of the reactor-pattern World.

R


On 30 Jan 2018, at 08:26, Stian Zeljko Vrba via Boost-users <boost-users@lists.boost.org> wrote:

Ok, thanks for the suggestion.

As a side-note, cancellation/shutdown seems to be the least thought-through feature in ASIO..


- it's an all or nothing thing, i.e., it can't be used to cancel individual I/O requests

- it doesn't work on completed requests

.. EVEN THOUGH the io service has a list of outstanding requests (waiting for completion) and pending (completed) handlers.

I could also just call stop() on the io_service, but when it's started again, all the "old" handlers will be called as well. The only complete solution probably being stopping and deleting io_service, and recreating it in the next "go".


-- Stian
From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of Gavin Lambert via Boost-users <boost-users@lists.boost.org>
Sent: Tuesday, January 30, 2018 4:27:46 AM
To: boost-users@lists.boost.org
Cc: Gavin Lambert
Subject: Re: [Boost-users] asio: cancelling a named pipe client
 
On 27/01/2018 06:50, Stian Zeljko Vrba wrote:
> Am I correct in assuming that cancel() is an apparent noop in this case 
> because of the race-condition where an I/O request completes 
> successfully before cancel is invoked?

Most likely yes.  It just internally calls through to the OS API, which 
will have nothing to do if there isn't an outstanding OS request at that 
exact moment.

ASIO can't internally consider this a permanent failure because there 
may be cases where you wanted to cancel a single operation and then 
start a new one that you expect to continue normally.

> If so, can you suggest a more elegant way  (i.e., a way that doesn't 
> induce a hard error) of exiting a loop as described here? Setting a 
> member variable instead of calling cancel?

Probably the best thing to do is to do both, in this order:

   1. Set a member variable that tells your completion handler code to 
not start a new operation.
   2. Call cancel() to abort any pending operation.

This covers both cases; if you miss the pending operation then the 
member will tell your completion handler to not start a new one and just 
return, and if you don't then the cancellation will generate an 
operation_aborted which you can either silently ignore and return 
immediately or fall through to the code that checks the member.

There's still a race between when you check the member and when the 
operation actually starts -- but that's why you need to post your 
cancellation request to the same io_service (and use explicit strands if 
you have more than one worker thread).

Omitting the cancel isn't recommended as this would prolong shutdown in 
the case that the remote end isn't constantly transmitting.

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users