Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-07 15:18:21

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> Beman Dawes wrote:
> 
> > 
http://groups.yahoo.com/group/boost/files/threads/thread_doc_snapshot.
zip
> 
> 	Thanks! So now you get my comments :-)
> 
> The motivation is only partially right. Even on single CPU 
machines, 
> we want multi-threaded programming, but there is no parallelism at 
all, 
> except deep in the CPU. So why not just say multi-threaded 
programming? 

This is picking nits.  Even on a single CPU machine there's 
conceptual parallelism.  No, it's not truly parallel processes, but 
from a design and motivational stand point that's not really 
relevant.  I can rework the wording slightly to make this more 
obvious, but I think it's overkill.

> 'xt is reached' ??
> 
> Try 'until xt milliseconds have elapsed
> since the function call began'?

Because 'xt' is an absolute time, not a duration.

> You need to give units,
> and to specify the initial event from which timing begins,
> and also specify how precise the timing is.

We can't specify how precise the timing is, because this is platform 
dependent.  Even at the point that this library is (theoretically) 
accepted into the language standard there will be no way to specify 
this.  As for units... that will be clearly documented once the xtime 
type is documented.  It's currently not documented because xtime 
doesn't really belong in Boost.Threads and I was hoping a complete 
proposal would be submitted to Boost before Boost.Threads was.  This 
isn't going to happen, however, so I'm going to need to document the 
minimal implementation included with Boost.Threads until such a time 
as xtime is fully submitted.

> The latter is non-trivial:
> I suspect you have to say 'when _at least_ xt milliseconds have 
elapsed,
> and when at most xt+IMPLEMENTOR_DEFINED_LIMIT milliseconds have 
elapsed.
> Then you need to  add that xt shall fall into an implementor defined
> range. Probably, this is all complex enough to warrant some
> 'front matter'.
> 
> In general --- this is really good stuff! I like the design,
> and approve of most of the design decisions. I get the feeling that
> 
> 	a) I could use the library easily having read the doco
> 
> 	b) it's beginning to 'spec down' the changes needed for the
> 	   abstract machine
> 
> 	c) the design lets me shoot myself if I want, or use safer
> 	   alternatives if I want
> 
> 	d) the decision to build a C++ library from ground up,
> 	   rather than wrapping a C API is well justified
>    	   by the actual design (and well explained in the doco)
>
> No, its not anywhere near ready for Standardisation.
> But it's very close to being immediately useful, and well on the
> track for gaining the experience needed -- with both the model
> and its documentation -- to prepare a submission for 
Standardisation.
> [And I'm not trying to be politically acceptable this time :-]

Thanks.  A lot of effort from a lot of people has gone into this.  
We're not all the way there yet, but we're close enough that after a 
bit more polishing I think we can submit and accept this into Boost.

Bill Kempf