pthread_cancel and EH: let's try this again

[David Abrahams]

Jason Merrill <jason at redhat.com> writes:

> 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.
>
> The main benefit of scheme #2 is that existing pthread_cancel-safe C++ code
> written to use pthread_cleanup_push/pop continues to work.  

What do you mean by "work?"  Can you explain the issues here, and show
just what would be broken by scheme #1?

> 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.
>
> This is also the rationale for choosing not to make cancellation a proper
> exception, which leads to scheme #2.

As Alexander says, a thread can always disable cancellation and never
re-enable it.  AFAICT, the idea that we can somehow force a thread to
cancel via a synchronous notification is just a myth.  I don't think
we can make any sensible decisions until face reality.

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