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