David Abrahams wrote:
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.Dave Butenhof <David.Butenhof@xxxxxx> 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.
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@xxxxxx ]--------------------\ | 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 ]---/