catch(...) and forced unwind

[Jason Merrill]

On 16 Dec 2003 21:28:10 -0800, Mark Mitchell <mark@codesourcery.com> wrote:

> On Tue, 2003-12-16 at 19:20, Jason Merrill wrote:

>> The two standards are incompatible as written.  To make pthreads and C++
>> play nice together, one or both need some adjustment.
>
> I agree.
>
> In my opinion, the most logical way to do this is to make the following
> changes:
>
> (1) In C++, the various POSIX thread cancellation points (e.g., "read")
> should have the exception-specification "throw
> (posix::thread_cancellation) rather than "throw ()".  They would throw
> an exception of this type if the thread is cancelled.

Yep.

> (2) The POSIX thread specification should allow a cancelled thread to
> uncancel itself.  After that point, the thread continues as if it had
> never been cancelled.  (It can be cancelled again, of course, after it
> is uncancelled.)  

It's not so much uncancelling as re-deferring cancellation--I assume that's
what you meant, but it sounds like you're suggesting that the cancellation
request be discarded entirely, which I don't think is appropriate.

There's still the question of what to do with pthread_exit.

> (3) The thread_cancellation objects contain a reference count; copying
> the object increments the reference count and destroying the object
> decrements the reference count.  If the reference count goes to zero (as
> would happen when the exception is caught and not rethrown) the thread
> is uncancelled.

This seems unnecessary.  Why would we need to copy the exception?  AFAICT
we would only need to change the cancellation destructor, which currently
calls terminate, to do #2 instead.

> (4) The POSIX thread specification should provide an interface (perhaps
> an additional field in pthread_attr_t) that indicates whether or not
> cancellation should result in throwing an exception.   The default will
> be to throw an exception.  However, if cancellation does not result in
> throwing an exception, the thread exits without even running cleanup
> handlers registered with pthread_cleanup_push.
>
> That way a library which depends on the strictly conforming C++ behavior
> can still be used in a thread.  There really are situations where the
> best behavior is going to be *not* to do stack unwinding at all. 
> There's no reason to expect that all C++ threads will need to have their
> stack unwound.

If you want to kill a thread without running any cleanups, there's always
pthread_kill.  If the C++ code can't cope with a cancel exception, it can
suppress cancellation with pthread_setcancelstate until it's ready.  I
don't think that your suggestion adds much.

Jason