
"William E. Kempf" wrote: [...]
1) What is pthread_null() (I can certainly guess on this one, but guessing could make a fool of both of us)?
extern "C" pthread_t pthread_null() { return pthread_t(); }
2) What is pthread_compare() and how does it differ from pthread_equal() (again, I could guess)?
extern "C" int pthread_compare(pthread_t tid1, pthread_t tid2) { return tid1 < tid2 ? -1 : tid1 > tid2 ? +1 : 0; }
3) What is pthread_hash() (probably the easiest to guess... but again...)?
extern "C" size_t pthread_hash(pthread_t tid) {
return std::hash
4) Why do *you* think any of these are necessary?
``Why not?'' ;-)
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.
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? ;-)
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)
(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.
http://tinyurl.com/buj9 regards, alexander. -- typedef std::kinda_dumb_thread_ptr pthread_t;