[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