$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: williamkempf_at_[hidden]
Date: 2001-10-29 11:27:15
--- In boost_at_y..., mda_at_d... wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > >if the latter, i can understand why the boost threads library
> > >was brought up. if the former, i don't -- that library has
> > >to my knowledge yet to appear in a boost release, and has not
> > >completed the boost internal process, to the extent that
> > >has been formalized.
> >
> > Boost.threads has passed formal review and is in the latest
> release. Plus
> > Bill Kempf was available to present it to the LWG in person.
>
> ah, yes, i now see it is in 1_25 (in fact its test directory takes
> more than 1Mbyte by itself...)
Huh? The test directory has 2 files, Jamfile at < 1KB and
test_thread.cpp at 12KB. That's a max of 13KB which is a far sight
from 1MB. In fact, the entire boost\libs\thread directory tree takes
only 314KB including CVS cruft (so the release in Zip format should
be even smaller).
> it was not however in 1_24.
> so it has been in a release for a month.
Very true.
> i've got nothing in particular against bill nor against the
> boost thread library -- i don't know either.
> i'm just thinking from my general experience that every API
> i've ever designed changed considerably by the time i'd
> shipped a product or two with it.
Yes, but with out trying to speak for the committee (which I can't
do) that's precisely why it's important to start considering such a
library. Before it can actually be accepted and standardized there's
going to have to be a lot of feedback from library implementors in
order to insure that a threading library meets the needs of
everyone. Don't confuse the interest in the library given by the
committee as a final acceptance. No new libraries have been accepted
yet.
> the only thing i can think of which is more controversial
> and complicated than threading is gui toolkits.
> i just can't believe that a few months of "shakeout" time is enough
> to understand the implications of any particular threading
> api proposal.
"Shakeout" generally speaks more to the implementation then to the
design, which is less interesting for the standard. Otherwise,
you're quite correct here.
Bill Kempf