pthread_cancel and EH: let's try this again

[David Abrahams]

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> Wil Evers <wil at bogo.xs4all.nl> writes:
>
> | Gabriel Dos Reis wrote:
> | 
> | > Wil Evers <wil at bogo.xs4all.nl> writes:
> | 
> | > | In other words, #2 has the desirable property that it does not break
> | > | existing code that assumes destructors *never* throw. I suspect that a
> | > | lot of code relies on that assumption, and I know for sure that
> | > | practically all of my code does.
> | > | | Supposing model #1 is accepted, then how do we cope with
> | > existing code
> | > | that assumes destructors never throw, or, more generally, with code
> | > | that was not written to deal with exceptions thrown from cancellation
> | > | points?
> | > Destructors that throw usually lead to brittle codes.  The
> | > problems are with those destructors, not with the cancellation model
> | > implemented for C++. The destructors should be fixed, because that
> | > problem is independent of multithreading.
> | 
> | I disagree; one of the problems with mapping cancellation requests to
> | C++ exceptions is that certain system calls that did not throw before
> | are changed into functions that do, and that existing (destructor or
> | non-destructor) code won't always be able to deal with that.
>
> If the function (or destructor) has a throw() specification, it will
> continue not to throw.  

Yeah, but at what cost?  Termination does not seem like a very
desirable response to a cancellation request that happens to occur
before a 'C' library call that ordinarily wouldn't throw.

> If it did not have that annotation then it was assumed to throw.

By the compiler, maybe, but not to programmers in general.  Few
programmers habitually use throw() on their destructors, but nearly
everybody who has learned to write exception-safe code assumes that no
destructor throws unless otherwise specified.

> If you want to have fine grained control, you might want to consider
> telling std::terminate() and friends not to abort().

What do you have in mind?

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