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

[Dave Butenhof]

< Foward Quoted >

>>Quite simply, I believe that is far too great a burden for the casual C++ user.  They are already struggling under the burden of a complicated language without us expecting them to understand intricacies of thread safety and lifetimes.
>>
>>The people actively working in the posix/C++ subset are much more familiar with these complex issues, and I believe the burden is on them to find a compromise that will not impact on the non-expert user who is NOT using this combination.  I do not pretend this is an easy task though ;¬)
>>    
>>
Cancellation does not affect application code (or coders) that don't 
want to use it. Nothing can cancel a thread without having the thread's 
handle through deliberate action of the thread's creator, or through 
pthread_self when executing within the thread. No modular "facility" can 
legitimately or reasonably do this to any thread to which it has not 
been granted "ownership" -- either by having created it within the 
facility or by having ownership handed to it through an explicit 
protocol (which is rare). Certainly some fool can chose, just for the 
heck of it, to cancel the thread in which it runs... but so what? It 
could just as easily generate a SIGSEGV and take out the whole process.

That one writes an application using threads, regardless of language, 
doesn't require you to use, understand, or even be aware of cancellation.

However when one writes a robust general-purpose facility (library) that 
will be used in an environment supporting cancellation, that library 
ought to be written to support cancellation (whether or not it actually 
uses cancellation on its own behalf). Such libraries are not generally 
tasks taken on by "casual users"; and even so while hardly ideal it's 
perfectly adequate to simply say "this facility isn't cancel-safe; tough 
luck".

"Industrial strength" libraries in the environment, for example the 
"language runtime" itself, whether libc or STL, ought to be cancel-safe 
certainly. Even at that, however, because the task can be monumental, 
POSIX provided "cheats" -- the list of "optional" cancellation points 
allow a libc developer to omit all but the most critical. A C++ standard 
for STL *could* provide similar "cheats" to avoid requiring full 
implementation of cancel-safety. And again, if the user of the library 
(whether the main application or another library) doesn't choose to use 
cancellation the point is moot.

And while Ted Baker has suggested that "loaded guns" shouldn't be given 
to "babies", one could respond cynically that it's far too late in UNIX, 
POSIX, C, or C++ history to worry about handing out loaded guns. 
(Cancellation is nothing compared to the explosive payload of an 
asynchronous signal, or even thread synchronization considerations.) 
With the existing well-stocked and easily accessible arsenal lying 
about, the addition of one more handgun can hardly be considered even 
relevant much less critical. And more importantly, there are many 
programmers who really DO know how to use those weapons of mass coding 
destruction, and need them. That's NOT a death ray over there in the 
corner, it's an industrial excavation tool; misuse is solely the 
responsibility of the user, not the manufacturer.

Finally, the question is NOT whether we choose to make these weapons 
available, nor even whether they'll be used. They already exist, are 
widely (almost universally) deployed; and are used and depended upon by 
many real applications. None of that is going to go away no matter what 
the C++ committee does. The question HERE is only whether there will be 
a STANDARD and PORTABLE specification to aid these developers and 
applications in moving between the various systems. Ignoring the issue 
won't make it go away -- merely leave those applications and developers 
with cumbersome non-portable code, and force someone to resurrect this 
same argument all over again in another year or two. (As indeed has 
already happened, through several cycles.)
-------------- 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/20050728/4ab3c3c9/attachment.vcf>