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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-05-16 08:58:20

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.
>
> http://tinyurl.com/buj9

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