[c++-pthreads] Re: thread-safety definition

[Dave Butenhof]

David Abrahams wrote:

>Dave Butenhof <David.Butenhof at hp.com> 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!)
>  
>
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.)

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 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 ]---/