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

Peter Dimov pdimov at mmltd.net
Sat Jul 23 19:08:16 UTC 2005


Alexander Terekhov wrote:
> Peter Dimov wrote:

>> But the problem is with existing user code that doesn't reenable
>> cancellation.
>
> That's either a bug or a feature of "existing user code". Make it
> cancel-aware. Complain about lack of portable C++ exception type
> identity for cancellation exception so that it can be distinguished
> from other exceptions (when you can catch multiple).
>
>>               The cancellation exception is swallowed by the
>> catch-all clause, the request is lost, and the cancel state remains
>> disabled.
>
> See above.

What happens in practice is not people making their code cancel-aware, it's 
either implementations breaking catch(...), coding standards banning 
catch(...), or both. (Such a coding standard makes perfect sense under such 
an implementation, of course.)

It boils down to this. The implementation of pthread_testcancel is:

if( request pending && cancelstate == ENABLE )
{
    set cancelstate to DISABLE
    clear request
    throw pthread_cancel_exception
}

but I think that a better alternative is:

if( request pending && cancelstate == ENABLE && not suppressed )
{
    suppress cancellation
    throw pthread_cancel_exception
}

with some kind of automatic un-suppression when the exception is finalized. 
The implementation may even have a separate "suppressed" flag and clear it 
at the point where the current GCC calls terminate. Or the suppression flag 
may be inferred from the current EH state in some way.

Ironically, this implementation was rendered invalid by the resolution of 
your DR.




More information about the c++-pthreads mailing list