boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: williamkempf_at_[hidden]
Date: 2001-07-31 10:40:07

--- In boost_at_y..., "Philip Nash" <philip.nash_at_c...> wrote:
> 
> Bill Kempf said:
> 
> > a null_mutex type can be coded up with out any effort at all
> 
> [..]
> 
> > For that reason I've not included this type [null_mutex] in 
Boost.Threads.
> It's
> > important that we get Boost.Threads accepted quickly, and this 
means I
> need to keep
> > the library "minimal but complete" for the initial submission.
> 
> I understand the reasoning as presented but I think that is a 
shame. I know
> a null_mutex is trivial to write, because I have written plenty :-) 
It will
> be nice when we can just use the one that is there (although, by 
definition,
> all alternate "implementations" should be interchangeable anyway).

It's trivial to write, yes, but it's complicated to get it exactly 
right as a general concept instead of a concept for a specific use.  
In other words, for inclusion in Boost.Threads proper we have to take 
into consideration such issues as compatibility (specifically lack 
there of) with boost::condition, etc., while usage in a library such 
as the sockets library under discussion can ignore such issues since 
they're an implementation detail.  I don't want the minute details of 
such a simple concept to cause any possible delay.  So I understand 
why the decision to leave this (and several other concepts) out is 
dissapointing to many, but that's just going to be the way it is. :(

> Anyway, what is the status of this submission now? I keep reading 
that it is
> "nearly ready" - is that still the case or have I missed something?

It's very close to being ready.  Beman and I are currently working 
hard on the documentation and cleaning up some issues revealed by 
this work.  I'm also considering a rework to the tss type that will, 
unfortunately, take a week or two to get right.  All that said, I 
expect to be ready to submit within a few weeks, barring any 
unforseen delays.

Bill Kempf