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

[Dave Butenhof]

Alexander Terekhov wrote:

>>As you can see, this leads to fixes that break catch(...) in a variety of
>>creative ways.
>>    
>>
Yes; and of course the basic issue is that in POSIX (and C99) there's 
nothing vaguely equivalent to "catch(...)"; and therefore no way the 
standard can address this.

>>>http://opengroup.org/austin/mailarchives/austin-review-l/msg01450.html
>>>      
>>>
>>So it was _your_ idea. ;-)
>>    
>>
>It did came to my mind... but its was Butenhof who authored the patch:
>
>http://www.opengroup.org/austin/mailarchives/austin-group-l/msg05916.html
>http://www.opengroup.org/austin/mailarchives/austin-group-l/msg05987.html
>http://www.opengroup.org/austin/mailarchives/austin-group-l/msg05989.html
>  
>
Alexander pointed out a problem in the "C Language binding to POSIX 
API", and I suggested a fix for that problem also in the context of that 
standard... the only context that was relevant.

Perhaps needless to say, I never thought that was ideal. There's just no 
way to express "ideal" without adding exceptions. POSIX made the 
decision that it wasn't remotely "in scope" to try to add "POSIX 
exceptions"; that this needed to be done by ISO C. POSIX cleanup (cancel 
and thread exit) cannot be finalized -- cleanup handlers are like 
Ada/Modula "finally" or C++ destructors, not like "catch" -- they 
cleanup, the return, and the unwind continues irrevokably until the call 
stack is empty and the thread terminates.

What was important, and relevant, was to make the cleanup handlers (and 
TSD destructors) reliable by specifying the state of cancellation. The 
original INTENT of the working group had been that cancellation was 
disabled implicitly by delivery, and most code is written presuming that 
state. Making all cleanup handlers and destructors that don't explicitly 
disable cancel suddenly "non-conforming" wouldn't have been a 
particularly useful amendment. (And it would also have been silly 
because all code a conforming application can run in the thread before 
termination ought to be non-cancellable as it's doing nothing but 
termination cleanup.)

As has been implied here, in my implementation, cancel re-enable, in the 
event that something outside "standard POSIX C" finalizes a cancel 
unwind, is the responsibility of the caller. That is, a C program that 
explicitly catches pthread_cancel_e, or identifies a CATCH_ALL exception 
as pthread_cancel_e, should itself enable cancellation if it wants the 
thread to become cancellable. A C++ binding could certainly choose to 
make that implicit, perhaps as part of the exception destructor. That 
the current implementation on Tru64 and OpenVMS doesn't do this is 
irrelevant to any future standardization. (Tru64 is being strangled to 
death along with Alpha, while OpenVMS never pretended to any more than a 
reasonable level of "convenience conformance" to POSIX or other 
UNIX-based standards anyway. That's not why people buy OpenVMS.)
-------------- 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/20050726/d4e2750e/attachment.vcf>