Re: catch(...) and forced unwind

[Mark Mitchell <mark at codesourcery dot com>]

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

Actually, I really meant uncancelling.  

I think that "catch (posix::thread_cancellation)" should just work
exactly as with catching any other exception.  I don't see any need for
special rules here.

You should be able to go on from there as if you were never cancelled,
just as you can call "longjmp" from a handler for "SIGTERM" and go along
from there.

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

The consistent thing would seem to be to have it throw
"posix::thread_exit".  (This, by the way, is analagous to the Python
idea that "return" statements are equivalent to throwing a special kind
of exception.)

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

If we do not allow uncancelling, then what you suggest is probably OK. 
This is a detail, in either case.

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

The point is to be able to use a strictly-conforming thread-unaware C++
library in a thread.  You can't have "printf" throw an exception because
that might break critical assumptions in the library.  With your
suggestion, the cancelling thread has to know that it should use
pthread_kill; I'd rather than the cancelled thread be able to say "I'm
not the kind of thread that can handle exceptions."

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