Re: catch(...) and forced unwind

[Mark Mitchell <mark at codesourcery dot com>]

On Tue, 2003-12-16 at 19:20, Jason Merrill wrote:
> On Tue, 16 Dec 2003 18:55:13 -0500, David Abrahams <dave@boost-consulting.com> wrote:
> 
> > Matt Austern <austern@apple.com> writes:
> >
> >> The real issue, of course is the old one: that the people defining the
> >> POSIX standard and the people defining the C++ standard didn't
> >> spend enough time talking to each other.  POSIX doesn't know
> >> anything about C++ contracts.
> 
> > Nor about standard C++ library functions, I presume?  Why should it
> > have any impact on the behavior of the C++ lib from a standards POV?
> 
> 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.

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

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

With these changes, library designers can still say "catch all
exceptions", but they can also say "catch all exceptions except thread
cancellation".  It may be that catching all exceptions is a bad idea,
but that is up to the library designer.

These changes are a pure extension to POSIX threads; they do not break
any existing POSIX threads code.  

These changes are not quite a pure extension to standard C++; the C++
standard prohibits C library functions from throwing exceptions, so, for
example, "printf" cannot throw an exception.  

Therefore, I would make one other change:

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

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC