Re: [c++-pthreads] cancellation points report failure
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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!

*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.

(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, 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.)

			--Matt