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

[Mark Mitchell]

Nathan (Jasper) Myers wrote:
> 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.  

That wasn't clear to me.

I'd be OK with that -- but most people seem to want POSIX thread 
cancellation to throw an exception in contrast with:

> There is no interaction between POSIX cancellation cleanup and C++ 
> exceptions, so no possibility of surprises, and no hard choices.

and GNU/Linux started implementing pthread_cleanup_push as a destructor 
a while back.  So, now, there's no way to run pthread cleanups without 
also doing stack unwinding.  To do bog-standard POSIX C cancellation 
semantics (i.e., without running destructors) would require changes to 
GLIBC (to put it back the way it used to be), and, of course, 
recompilation of all pthread_cleanup-using binaries.

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

True -- but that is in fact the behavior that was defined in the last 
iteration of that debate that the behavior shown was what was wanted. 
That behavior isn't an accident.

>>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.

I agree that the choice doesn't matter much.  Heck, this whole issue 
doesn't matter much to me; I'm just trying to keep us from going in some 
really bad direction...

> 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.  

Nothing we're talking about requires compiler support per se; it's all C 
library support -- including your proposal, if I understand it 
correctly, since you want to not do unwinding when inside a cancellation 
region, which requires changing pthread_cleanup_push not to be a destructor.

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com
(916) 791-8304