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

[Dave Butenhof]

Peter Dimov wrote:

> Peter Dimov wrote:
>
>> It's certainly questionable whether a cleanup handler (TSD 
>> destructor) that explicitly enables cancellation and calls a 
>> cancellation point should re-cancel itself... and if it does, whether 
>> it should re-invoke itself, so it might be argued that this 
>> clarification introduced a new problem instead of fixing the old.
>
> Scratch that, if this:
>
> "The cancelability state shall remain set to PTHREAD_CANCEL_DISABLE 
> until the thread has terminated. The behavior is undefined if a 
> cancellation cleanup handler or thread-specific data destructor 
> routine changes the cancelability state to PTHREAD_CANCEL_ENABLE."
>
> made it into the TC, it specifically prohibits the scenario I 
> described. It also appears to prohibit enabling cancellation after 
> catch(pthread_cancel_e) without rethrow, effectively disallowing catch 
> without rethrow ("shall remain set to...").

That's an intrinsic requirement of the C binding to POSIX; there's no 
catch, only cleanup handlers which implicitly and irrevokably "rethrow". 
(And aren't allowed to interfere in any way with the unwind.) It's not 
just cleanup handlers that need cancel disabled, but also TSD 
destructors, which run only when the thread has been fully unwound. We 
can't say "if", because in POSIX there's no if... the thread IS fully 
unwound, and TSD destructors DO run; but concession to a catchable 
cancel in some other language binding would mean breaking those scopes 
in two... possible, yes; but more complicated and pretty hard to justify 
in the current standards environment that's C-only and exception-phobic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20050727/34e2c779/attachment.vcf>