Re: [c++-pthreads] cancellation points report failure

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Matt Austern <austern@xxxxxxxxx> writes:

> On Dec 19, 2003, at 12:44 PM, David Abrahams wrote:
>
>> Nathan Myers <ncm@xxxxxxxxxxx> writes:
>>
>>> 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.
>>
>> Ingenious!  I'm not sure about all the implications, but I think we
>> should explore this idea further.  In hindsight, it's almost obvious:
>> a function should only report failure in one way.  Requiring
>> programmers to deal with exceptions *and* failure status makes the
>> whole thing unwieldy and error-prone.
>
> I'm not sure it really solves the problem, though.  Yes, it's good for
> read() to report failure if the thread is cancelled.  But we should also
> make sure that the thread really does get cancelled!

There really is absolutely no way to *make sure* of that other than by
using async cancellation, though.  Even if you throw an exception, the
thread can catch it and resume normal work inside the catch handler if
it wants to -- in that case, the compiler has no way to detect that
we're not responding to it.  I admit that's a somewhat perverse case,
but my point is that the best we can hope to do is come up with a
model which works out most of the time and is likely to be compatible
with existing coding patterns.

> *If* we are using a special exception type to represent thread
> cancellation, then we had better make sure that we get a cancellation
> exception somewhere within the thread---if not from read, then at
> least later.  We can defer the exception to a later point where the
> program knows how to deal with it, but we shouldn't eliminate it.

Of course pthread_testcancel would still throw (once?) if a
cancellation request had been issued but the thread was still running.

> (Maybe we should take a step back and ask why we're thinking of
> representing thread cancellation as an exception.  Rationale: we
> want to make sure that the cancellation isn't ignored

I've never bought the idea that exceptions "make sure errors aren't
ignored".  There's plenty of code that ignores the possibility of
exceptions; it's just as broken as code that ignores error return
codes.

If you really mean "make sure the cancellation really unwinds the
whole thread", well, we can't do that either because the exception may
not be able to traverse language boundaries safely.

> but we also want to give the thread a chance to do some cleanup
> before it dies.  In C we might have cleanup callbacks.  In C++
> exceptions seem like the natural choice.  I think everyone who has
> done a C++ binding for POSIX has made that choice, but it would be
> interesting to hear of counterexamples.)

I'm not sure if this is relevant:

In a recent conversation I had with David Butenhof about "2-phase
exception handling" we discussed the possibility that there's a
special subset of all the cleanups "on the stack" which needs to be
run even when termination is forced (e.g. for things like assertion
failures, and possibly thread cancellations(?)) in order to release
global resources like file locks.  2-phase EH provides a language
mechanism for addressing that need, though IIRC there are some cases
it doesn't actually handle.  In any case, I don't think mandating
2-phase EH in the C++ standard would be appropriate.  You can,
however, build a fairly elegant library solution using
set_terminate_handler() which handles all the cases.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com