Alexander Terekhov said:
5) What "needs to be done in order to provide 'symmetry' with respect to <thread>/boost.thread stuff"? My participation in the Open Group? My understanding of what they're doing? The inclusion of the above functions to POSIX threads?
Well, pls see above and below.
This is pretty much the first time
I've 'mentioned' it here before -- in the 'Pro-"pthread_null/compare/hash" lobbying association' sig.
That is hardly "mentioning" it. You can't expect someone to even read your sig. And what is in your sig is hardly enough information to warrant the term "mentioned", even if I had read it.
I've heard of these functions, so asking me to champion them with out more meat is still not the best form of "saying what you mean".
But it's somewhat better than before, right? ;-)
Better, but hardly good enough. Look... I respect your knowledge on this subject, but for your knowledge to be useful to anyone you have to work on your delivery.
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. All that said, I will at least be reading about this, so despite my frustration, I'll thank you for the heads up.
(In fact, the only one not provided for in the implementation in thread_dev is thread_null(), assuming I'm making the right guesses as to what these functions are. It means specifying some requirements on the ID in the documentation, but the implementation already provides this. I've debated thread_null(), as I do see uses for it, but that would require a backwards incompatible change to the interface, so I've got to make the decision carefully.) So there's not a lot of reason for me to champion them in the Open Group, though there is reason for me to be interested in any debate or resolution that occurs there.
Another classic example of your poor communication skills. This link leads to a lengthy discussion. It will take me a significant time to read the full thread, and even more time to figure out why I should even care (in relation to *this* thread of discussion). At least tell me what I'm looking for. Better yet, summarize the point you want to make by referencing this discussion. You're method *might* save you a minute or two in posting, but it will cost me many factors more than that in figuring out what you want to say. If you don't care enough about what you're saying to actually say it, why should I care enough about it to spend the time trying to figure it out? -- William E. Kempf