Re: catch(...) and forced unwind

[Mark Mitchell <mark at codesourcery dot com>]

> > That isn't very useful.  Just to step back a moment, can we all
> > agree that we want pthread cancellation to run C++ cleanups?  
> 
> I think so.

Having cancellation result in throwing an exception seems reasonable.  

The only other plausible alternative is not unwinding the stack.

That does seem inferior, but I'm not sure it's as bad a choice as people
seem to think.  After all, you could always get SIGKILL, which might
leave resources lying around.  If pthread_cancel just killed the thread,
the remaining threads have the same problem that remaining process have
after one of their brethren is SIGKILL'd.

> > And that we might have to adjust a few things to make that work?
> 
> Yes.  The only things I think are crucial here is that functions which
> are specified not to throw (or conditions which are specified not to
> throw) continue to not throw anything, including cancellation, and
> that whatever guarantees functions give about program state in case
> they throw an exception also apply if the exception is a thread
> cancellation.  Almost without exception (NPI), code that works in the
> presence of exceptions does not depend on the meaning of said
> exceptions, so giving cancellation exceptions any kind of special
> license to violate assumptions made about other exceptions would be
> wrong.

I agree.

That is essentially what I argued the last time: we should just treat
cancellation like throwing an exception of a special type, and have an
implicit handler for it outside the first function called when the
thread was started.  This implicit handler would just terminate the
thread.

If the exception is caught, fine, the thread is not cancelled.  If the
exception causes the program to violate a throw spec, fine, the program
calls unexpected().

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