Re: [3.3] Followup to C++ forced unwinding

[Nathan Myers <ncm at cantrip dot org>]

On Wed, Apr 30, 2003 at 04:16:34PM -0700, Ulrich Drepper wrote:
> Richard Henderson wrote:
> > On Wed, Apr 30, 2003 at 03:55:06PM -0700, Mark Mitchell wrote:
> > [...]
> >>If the catch-clause chooses not to rethrow the exception, that just
> >>means this thread isn't going to be cancelled, which could happen from
> >>an ordinary pthread cancellation handler.  Deferred cancellation
> >>semantics don't give you any guarantees about when a thread will exit
> >>after it has been cancelled.
> 
> No, this is not acceptable.  Once cancelled a thread cannot be allowed
> to prevent this.  Cancellation changes the internal state of the thread,
> it cannot continue running.  The POSIX standard is clear on that, if a
> thread leaves the cleanup handler in some way the behavior is undefined.
>  The rethrow is mandatory in case the catch blocks are expected to run.
>  There is no discussion possible, this is a fact.

Any thread can prevent cancellation by putting "while (true);" in
a destructor.  Once control leaves the catch block, the thread can't 
do any more externally visible work anyway, because that would touch 
another cancellation point, which (I assume) would throw again.  

If and only if throwing again can't be made to work, then you may
declare that a catch(...) clause not rethrowing a cancellation 
exception results in undefined behavior.  It is already considered 
poor practice for a library not to rethrow unidentified exceptions.  
Normally, swallowing unknown exceptions is done only in a main 
program, or if in a library, then only because the library is meant 
to be called from a language that cannot handle exceptions.  Neither 
consideration applies here.

> And your assessment that single-threaded and multi-threaded apps behave
> differently is wrong, too.  There is no way a single threaded app can
> get cancelled.  Normal termination, via exceptions or not, is different
> from cancellation.

No.  Exception-safe code is also (almost always) thread-safe as well,
and users reasonably expect exception-safe library code to be usable
in a thread.  You cannot announce that exception-safe code that has
been in long use is suddenly not thread-safe any more just because 
you chose to break the language's exception semantics.

> If catch blocks are executed they must be converted in in "finally"
> blocks with automatic rethrow.  I'm not sure whether catch blocks should
> be handled, my gut feeling is no.

There is no need to convert blocks to automatically rethrow.  Coders 
can take responsibility for their own code.

Nathan Myers
ncm@cantrip.org