catch(...) and forced unwind

[David Abrahams]

Mark Mitchell <mark@codesourcery.com> writes:

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

Huh?  No, not IIUC.  The other mode will throw exceptions from 'C'
lib functions, right?

I want to be *able* to say, "don't throw any cancellation exceptions
at me except where I explicitly call pthread_whatever_its_called (the
one which just throws if there's a cancellation pending and does
nothing otherwise)".  There's nothing wrong with your other modes,
but IMO the mode I'm describing would provide the safest route to
integrate library source code into a threaded app.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com