[c++-pthreads] Re: I'm Lost

[Dave Butenhof]

Alexander Terekhov wrote:

>Wil Evers wrote:
>[...]
>  
>
>>I'd say it's time to face the truth, which is that POSIX cancellation
>>semantics are incompatible with commonly established C++ coding
>>practices.
>>    
>>
>It's incompatible with cancel-unaware C++ code. Note that it's 
>incompatible with cancel-unaware C code as well, but that didn't 
>stop POSIX and ongoing creation of cancel-safe code in both C 
>and C++ languages. Very many tons of cancel-safe code.
>  
>
Indeed. The only real (and unfortunately the hardest) questions are how 
to reconcile the (apparent) contradictions between cancel scope and C++ 
throw specs (explicit or implicit as in destructors), and cultural 
investment in catch(...).

Perhaps integration would be simplified if threads created using native 
C++ mechanisms (rather than the C pthread_create) started with 
cancellation disabled, allowing C++ programs to enable where desired. 
Then again, though, it's important to keep in mind that a thread is not 
subject to cancellation unless some thread with access to the thread ID 
CHOOSES to cancel it; nobody can force cancellation on a thread without 
its ID, and thread IDs are not generally available. And while any 
routine can cancel the current thread (pthread_self), doing this without 
certain knowledge that the thread's call stack can handle it is a pretty 
stupid programming error.

Cancellation is not like 'kill <pid>', forced arbitrarily from outside 
forces unknown; it's a COOPERATIVE request from friendly code. Only code 
running inside the thread, or code that closely collaborates with the 
creation or management of the thread (by prior agreement) can ever 
cancel a thread.

And the C++ committee could define C++ threading without cancellation; I 
think that would be a mistake in the real world, and I know many others 
will, but the committee need not care. However, if C++ has cancellation 
it has to be cleanly integrated with C/POSIX cancel and cleanup, and the 
only viable language/implementation model is to make cancel an exception.
-------------- 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/54d85dc6/attachment.vcf>