cancellation points report failure

[Nathan Myers <ncm@xxxxxxxxxxx>]

On Fri, Dec 19, 2003 at 10:28:46AM -0800, Matt Austern wrote:
> 
> One possible solution (perhaps overly drastic): in C++, eliminate
> all cancelation points except for pthread_testcancel.

Another would be for those functions identified as cancellation 
points to report failure.  In particular, a read() call should return 
immediately.  Existing (good) code has to handle normal failures 
already.  Well-designed library code will propagate the failure up 
to the point where a check for cancellation, and throw, may occur.  

To me, the whole problem is how to salvage libraries, both C and C++.  
I don't know how to write C library code to maintain invariants against 
stack unwinding.  By contrast, a main program that the author knows will 
be running threaded can reasonably be expected to perform heroics to
accommodate cancellations.  Our task is to get those cancellations
propagated, reasonably quickly, to a context that expects them, without
demanding that the libraries do anything unusual.  Any place where an
exception is allowed, though (such as operator new() and filebuf::
overflow()) seems like a reasonable place to turn the cancellation into 
an exception.

I expect that no matter what we do, some libraries will fail to 
respond properly to a cancellation.  Code that fails to check for 
write() failure is common, and for printf() even moreso.  That's too 
bad, but we needn't agonize over it.  The set of libraries available 
to threaded programs has always been restricted.  A requirement of 
correct response to failures seems not to great an additional 
restriction.

I don't like the idea of ever entirely discarding a cancellation.  If 
a cancellation exception is thrown, caught, and discarded, I would like
to see it surface again at the next opportunity.  I think that means 
that, e.g., I/O operations might be allowed in exception-handling code
being run during the cancellation unwind, but if one of those handlers 
were to swallow the exception, the next I/O operation would fail or
throw another cancellation.  The idea is not to let the thread get
much further without finding cause to bubble up toward the top-level
caller that knows it's in a thread, and can die gracefully.

Nathan Myers
ncm@xxxxxxxxxxx