Re: catch(...) and forced unwind

[Mark Mitchell <mark at codesourcery dot com>]

> >
> > If, on the other hand, you let go of all references to the
> > thread_cancellation object, then you decided you do not want to be
> > cancelled at all.  
> 
> *This time*.  Because by letting go of the cancellation object, you
>  re-enable cancellation points.  That's kind of an odd paradox isn't
>  it?

Yes, that re-enables cancellation points.  I don't know if that's an odd
paradox. :-)

> > the same problems come up with cooperating processes in the presence
> > of signals. A correct program, written for an environment without
> > SIGTERM, must be audited before being deployed in an environment
> > with SIGTERM.
> 
> Yeah, but signals were fundamentally different from exceptions until
> the posix/c++ standard conflict about which functions can throw arose.

The point is that both SIGTERM and thread-cancellation are ways that
some external influence can try to make your thread of control
terminate.  In both cases, you have to figure out what resources you
need to deallocate when that happens.  Alternatively, in both cases, you
can block the external interrupt.

> > In one mode, the C++ thread sees a conforming C++ environment (i.e., one
> > in which "printf" never throws exceptions).  Stack unwinding will not be
> > done in that environment, so if such a thread is cancelled, it will not
> > get a chance to clean up after itself.  
> 
> Y'know, I don't like that.  It doesn't give people the choice to add
> explicit cancellation checks to a codebase while preserving the C++
> standard behavior of functions that don't throw.  If I was trying to
> import some generally-threadsafe code to a threaded environment,
> looking for a few places where it's safe to throw cancellations would
> be my first strategy.

So, then, you would want to use the other mode. :)

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