pthread_cancel and EH: let's try this again

[Peter Dimov]

Jason Merrill wrote:
> OK, let me clarify my position.  For a new C++ threading library, I
> would continue to prefer scheme #1.  But this isn't a new library,
> it's an extension of an existing library.

But if it becomes part of the C++ standard, it becomes part of all C++ 
libraries, including new C++ threading libraries.

> Tangent follows:
> ----------------
> WRT scheme #1, various people have wondered why re-asserting
> cancellation in the exception's destructor is necessary.  It's
> necessary because as I said in my first message, if someone
> specifically told the thread to go away, they don't want it to
> recover, they want it to go away.  The thread doesn't get to
> second-guess that request, it has to go away.  It can take
> arbitrarily long to get around to actually going away, but it can't
> actually decide not to.  It especially can't decide this implicitly,
> as a side-effect of code written to handle exceptions.

Keeping the cancellation request active doesn't need to be done by 
reasserting in the destructor. It can simply be left active. Since 
cancellation is implicitly disabled during stack unwinding, the request will 
automatically "reassert itself" when the exception is caught, independent of 
how many times the exception is copied and destroyed.

Providing a way to clear a cancellation request is useful when tasks are 
executed in a thread pool and it's only the task that needs to be cancelled, 
not its thread shell.

If a thread has been explicitly written to oppose cancellations, there is 
little to be gained by twisting the rules to make it cancellable. The thread 
has been designed as uncancellable. It will probably break if cancelled.