< Foward Quoted >
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.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 ;¬)
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.)
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