David Abrahams wrote:
Sure, and POSIX has always had the same philosophy. We've even done some things to avoid entirely precluding braindead trivial implementations (like pure user-mode emulation packages). But we didn't go out of our way to make things EASY for them, either. We don't allow the operations of any thread to prevent any other thread from making forward progress, for example. (E.g., a braindead user-mode library can't let any thread make a direct kernel blocking I/O call; fully implementing that on UNIX is actually impossible, because select() and poll() traditionally "lie" about file-based I/O operations... but even ignoring that complication it isn't easy.)Dave Butenhof <David.Butenhof@xxxxxx> writes:We could require the language to perform some call stack analysis as part of deciding whether to deliver a cancel in the first place --I think this falls into the same category as 2-phase EH: a nice thing for implementations to provide, but not something we can mandate in a standard without significantly raising the barrier-to-entry for a conforming C++ implementation. Remember that the simplest EH mechanisms are based, essentially, around a very naive setjmp/longjmp-like mechanism. Granted, they suck, but traditionally we on the C++ committee have shied away from legislating quality (no wisecracks from the peanut gallery, please!)
So whether your argument is relevant depends a lot on where this feature sits. If it's something that "might be nice" but isn't really important for portable applications to have, then yeah, maybe it sits above the bar. I know you have that opinion of 2-phase EH, for example, and as much as I like it I don't strongly disagree. But that's not a foregone conclusion for THIS feature, or any other. And if it's decided to be important then the fact that it makes life hard for someone who wants to ship a braindead implementation should be irrelevant.
At least in theory. And, in theory, there's no difference between theory and practice. ;-)
-- /--------------------[ 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 ]---/