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

[Dave Butenhof <david.butenhof@xxxxxx>]

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.
begin:vcard
fn:Dave Butenhof
n:Butenhof;Dave
org:Hewlett-Packard Company;Manageability Systems Lab
adr;dom:110 Spit Brook Rd;;ZKO2-3/Q18;Nashua;NH;03062
email;internet:david.butenhof@xxxxxx
title:HP Utility Pricing software agent Technical Lead
tel;work:603.884.7460
note;quoted-printable:POSIX thread standards consultant=0D=0A=
	Author of "Programming With POSIX Threads" (Addison-Wesley)=0D=0A=
	Father to Amy (12) and Alyssa (8)
x-mozilla-html:TRUE
version:2.1
end:vcard