[c++-pthreads] cancellation points report failure

Jason Merrill jason at redhat.com
Wed Dec 24 12:51:37 UTC 2003


On Sat, 20 Dec 2003 10:54:44 -0800, Mark Mitchell <mark at codesourcery.com> wrote:

>> Since it apparently isn't yet clear to everybody what I had suggested,
>> I'll outline it again:
>
> I think it's a great to see a tidy description of your idea.  It's good
> to get concrete proposals on the table.
>
> Jason (Merill), would you care to post a similar description of your
> preferred scenario?

The scenario I've been thinking of is:

 * The POSIX cancellation points can throw a cancellation exception.
 * C++ I/O functions can throw a cancellation exception.
 * C++ catch blocks work normally.
 * If a cancellation exception is destroyed, the cancellation request
   is re-entered, and acted on again at the next cancellation point.

This model doesn't work as well for pthread_exit or longjmp_unwind, since
they don't have predefined deferral semantics.  I'm somewhat inclined to
stay with calling terminate if we swallow an exit exception.

I just did some testing on Tru64: Evidently in their structured
exception handling model, finalizing a cancellation exception discards the
cancellation request, as Mark was suggesting; ditto for pthread_exit.  And,
interestingly, abort().  Testcase attached below.

The main problem with extending these semantics to C++ is the iostream code
which traps all exceptions.  I think this is a mistake in the design of
iostreams, but it seems likely to be a common mistake, and I feel strongly
that it shouldn't silently discard the cancellation request.  That would
almost certainly be an unintended side-effect.

Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-c
Size: 712 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20031224/390d71d0/attachment.bin>


More information about the c++-pthreads mailing list