Alexander Terekhov said:
"William E. Kempf" wrote: [...]
BTW: If the above functions are what I think they are, I can provide them in Boost.Threads with out anything being changed in the POSIX standard.
We need a POSIX.C++ standard, that's why you and others should join the Austin group. (check out some messages on the "Austin Off Topic Discussion" reflector)
Why do we need that?
I'm not trying to say that it's a bad idea, but POSIX is not a standard that's universally adopted, and is focused on language extensions. It's more than worth considering what the POSIX standard says and does by Boost.Threads, and it would be folly for me to recommend to the C++ standards committee any library that violated POSIX in any way, or was counter to POSIX, or couldn't leverage current or future POSIX standards. But that doesn't mean that I should have a vested interest in shaping a POSIX.C++ standard.
Here's an illustration. (no link this time; see c.p.t. for details)
<quote>
Ok, ok. I agree that a strictly confirming *application* should rely on guaranteed thread termination and always-unwinding. Perhaps we have a "scope" problem here, again. All I want is that a strictly conforming *function* shall not rely on unwinding IF it can be invoked within a C++ scope/functions that could restrict propagation and unwinding using exception specifications. There just ought to be some loophole/hint for that, don't you think so?
No, I don't, because none of this is even remotely within the scope of the POSIX standard. POSIX deals with thread cleanup handlers, which are called before the thread terminates. Period. There's no finalization; there's no chance of process termination. It is completely irrelevant to "strictly conforming" POSIX implementations or applications what might happen if it were, hypothetically, possible for an "unhandled" "exception" to terminate the process, because neither "unhandled" nor "exception" are meaningful concepts.
IF there were a "C++ binding to POSIX", and IF that binding said that the mechanism for POSIX cleanup was actually "C++" exception propagation, this would need to be covered. But that hasn't happened and very likely won't happen.
</quote>
From my perspective (and I would assume the perspective of the C++ committee), what's important is that anything I do in Boost.Threads needs to be compatible with POSIX (as well as other threading systems), but
The motivations are backwards here, though. If the C++ language adopts a threading library, POSIX systems will have a lot of motivation for defining a POSIX C++ binding, or at the very least, making a particular implementation's POSIX binding compatible with the C++ threading. that's really it. I don't have any vested interest in extending POSIX for any reason. So, I'm intested in what's going on, but I'm not a good candidate for helping champion any proposals you're making for POSIX. -- William E. Kempf