Re: [Boost-Users] Re: boost::mutex::scoped_lock conventions

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-05-15 11:19:52

Alexander Terekhov said:
>
> "William E. Kempf" wrote:
> [...]
>> I'm going to try this one time.
>>
>> Say what you mean to say, or don't say anything at all.
>
> This time, I want to say that you should finally join
> <www.opengroup.org/austin> and start your activity there
> with some explanation why the <pthread.h> AND the
> upcoming <cthread> header should really define something
> like pthread_null(), pthread_compare() and pthread_hash(),
> extern "C++" pthread_once()-and-etc.-with-function-ptrs
> from <cthread> aside for a moment. I'd just say that this
> needs to done in order to provide some "symmetry" with
> respect to <thread>/boost.thread stuff, or something like
> that.

Slightly better communication than you've done in the past... but:

1) What is pthread_null() (I can certainly guess on this one, but guessing
could make a fool of both of us)?

2) What is pthread_compare() and how does it differ from pthread_equal()
(again, I could guess)?

3) What is pthread_hash() (probably the easiest to guess... but again...)?

4) Why do *you* think any of these are necessary?

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?

This is pretty much the first time 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".

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. 
(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.

-- 
William E. Kempf