[c++-pthreads] Re: cancellation points report failure

[Dave Butenhof]

David Abrahams wrote:

>Dave Butenhof <David.Butenhof at hp.com> writes:
>  
>
>>Since a "phobia" is an "abnormal or illogical fear", I'd have to say
>>you're wrong on two counts. First, I don't fear it; I merely argue
>>that it's rarely usable and far too easy to misuse, and that the cost
>>of the feature outweighs its value. And none of that is
>>"illogical". Furthermore, since some of the C++ people here seem to
>>have enough trouble with the idea of cancel as an exception in the
>>first place, (one of those rare goals in which you and I are united),
>>nevermind introducing the concept of an ASYNCHRONOUS exception, let's
>>just leave this alone, eh?
>>    
>>
>I, at least, have no trouble with the idea of using C++ exceptions to
>report cancellation.  In fact, I think it's a great idea in general.
>It's just a really bad idea for functions which can normally be
>expected never to throw exceptions to start throwing cancellations
>when used in a POSIX threads environment.
>
>IIUC, other "C++ people" who don't like the idea of printf throwing
>an exception feel the same way.
>  
>
Although I wasn't counting you in particular as an objector, I may have 
overgeneralized the objections of others. The whole matter of 
interaction with throw specs in particular is complicated, and I 
certainly don't claim to have any answers -- easy or otherwise. I've 
considered making a couple of rambling conceptual statements, but I'm 
way out of my league here on C++ philosophy and history, and I wouldn't 
want anyone to think I'm doing more than idle speculation.

One of those idle thoughts was that the concept of "cancel state" 
(enable or disable) might even be meaningless (or at least irrelevant) 
for a pure C++ binding. This might simply be a dynamic property of the 
current call tree; depending on the nested throw specs. That is, if the 
cancel exception can be thrown, cancel is "enabled"; and if it cannot 
then cancel is "disabled". This might well make it too hard to ever 
allow cancellation, since "most" throw specs would probably need to 
include cancellation. (That it might also make everything without a 
throw spec cancellable I discount as irrelevant: that's only an issue if 
the code runs in a thread that can be cancelled, in which case the code 
is so far out of any supported boundaries now that I don't care. This of 
course doesn't disallow or invalidate the possibility that YOU care. ;-) )

That also doesn't help in dealing with "printf throwing an exception" in 
the most generic sense, if that's taken as a placeholder for "library 
routines that don't currently raise exceptions but ought to be 
cancellation points, including read and write. In particular, though, 
POSIX designates printf as an OPTIONAL cancellation point. Most current 
implementations do NOT support cancellation of printf because it'd mean 
putting handlers into the C runtime to clean up stdio state. (On Tru64 
UNIX, for example, handling exceptions requires linking libexc, on which 
libc has never depended, so adding cancellation support to libc would be 
"a big deal".) If printf isn't a cancellation point, then it shouldn't 
normally be expected to raise the cancel exception. ;-)

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/