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

Jason Merrill jason at redhat.com
Tue Jul 12 15:39:27 UTC 2005


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.  This seems like
a basic requirement for an implementation of pthread_cancel, and one that
the current implementation on linux systems violates.  This is currently
causing real problems for real users; we are breaking their code that used
to work under linux and continues to work on other platforms.

Choosing scheme #2 requires us to choose to say, as Jakub suggests, that
cancellation is NOT logically an exception.  We just happen to implement it
using the EH infrastructure.  This is the same choice that Ada made, and
one that I have become more sympathetic to.
http://www.codesourcery.com/archives/c++-pthreads/msg00069.html

Compatibility with existing pthreads code is more important than
consistency with C++ exceptions.

The effect of this is that where before pthread_cancel-safe code needed to
use pthread_cleanup_push/pop for cleanups, now users can just put their
code in destructors.  Or they can continue to use
pthread_cleanup_push/pop.  This is a pure extension, whereas the current
implementation and scheme #1 are incompatible changes.

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.

Jason



More information about the c++-pthreads mailing list