[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