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

[Peter Dimov]

Wil Evers wrote:
> My objection to model #1 (and, to some extent, #2 as well) is that is
> breaks some commonly used assumptions such as 'destructors do not
> throw' (#1) or 'system calls do not throw' (#1 and #2).  Implicitly
> disabling cancellation during stack unwinding solves some of the
> problems that are introduced by mapping cancellation requests to C++
> exceptions, but not all of them.
>
> It seems to me that a complete solution compatible with #1 - one that
> preserves existing semantics, except for the places where we are know
> we are able to deal with cancellation exceptions - requires the use
> of an idiom like the one I tried to illustrate above.  And - I'm
> repeating myself here - once the user has put all this in place,
> there is no need for the cancellation machinery to implicitly disable
> cancellation at all.  It makes no difference any more - just as you
> observed.

I agree that if people always disable cancellation in destructors implicit 
suppression doesn't matter.

But we have a number of conflicting goals. We want:

1. To specify sensible C++ cancellation semantics for new C++MT code.
2. To not break existing C++ code much.
3. To not break existing Posix code much.

Since Posix semantics are approximated quite well by just suppressing 
cancellation during stack unwinding, and since this suppression (arguably) 
doesn't affect old C++ code or new C++ code in a negative way (*), it seems 
a good compromise.

We also want

4. To not break C++ exception handling or introduce special cases.

which is why I think that #1 with implicit suppression is the best 
alternative of those described so far.

(*) A function that tells us whether stack unwinding is in progress could 
even prove useful for new C++ code.