[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Gabriel Dos Reis]

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.  If it did not have that annotation then it was
assumed to  throw.

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

-- Gaby