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

[Nathan (Jasper) Myers]

On Wed, Jul 20, 2005 at 05:42:57PM -0700, Mark Mitchell wrote:
> Nathan (Jasper) Myers wrote:
> > * During the lifetime of C, the semantics of destructors and catch 
> >   blocks are undefined if the thread is cancelled and a POSIX C 
> >   cancellation point is encountered.  Any cleanup ends at the scope 
> >   of C, and control leaves this scope via an ordinary exception.
> >   
> > * Outside the scope of a cancellation_context, the effect of 
> >   pthread_cleanup_push etc. is undefined.
> 
> It sounds like you're coming up with entirely new thread semantics that 
> have nothing much to do with POSIX thread cancellation, in that they 
> seem to leave the POSIX thread cancellation behavior undefined.

Within a cancellation context scope, you have bog-standard POSIX C 
cancellation semantics.  Outside it, you have standard C++ semantics.  
There is no interaction between POSIX cancellation cleanup and C++ 
exceptions, so no possibility of surprises, and no hard choices.
(Anybody who provides definitions can do it without breaking any 
code that doesn't depend on them.)

The point is to keep POSIX thread cancellation from breaking every 
library.  C++ code is mostly useless without libraries, and libraries 
as a rule know nothing about cancellation.  

> For example, this program presently works on GNU/Linux (tested on RHEL 3):
> ...

Of course testing doesn't tell you whether it has defined behavior.

Most users don't use cancellation because it doesn't work right with 
C++.  The only people who using cancellation with C++, and happy, are 
self-selected: the ones who don't care that it doesn't really work.

> That means that the most important question we should answer is what to 
> do for the program above, when the "throw;" is removed.
> 
> I think the only reasonable choices are:
> 
> 1) Fall off the end of the catch clause in the usual way, but the thread 
> is still cancelled.  Encountering another cancellation point will result 
> in re-raising the cancellation exception.
> 
> 2) Fall off the end of the catch clause in the usual way, but the thread 
> is no longer cancelled.  It can be re-cancelled, but until it is, it 
> will operate normally.

It doesn't matter much which it does; probably (1) is fine, as far as 
that goes.  Neither choice addresses the problem that the libraries we 
all depend on are unusable -- or worse, seem usable until it matters 
-- in threads that might be cancelled.  Testing doesn't reliably tell 
you if it matters.

Making the spec depend on compiler support practically guarantees 
that most users won't get anything reasonable, because that depends 
on "uptake" by people implacably hostile to C++.  That's whey we're 
at this impasse in the first place.  

Nathan Myers
ncm at cantrip.org