Date: 2001-06-23 12:06:02
--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Beman Dawes wrote:
> > Ross Smith wrote:
> > >(Then again, possibly I'm not the best guy to be putting his
oar in at
> > >the moment; I'm not very keen on what I've seen of the Boost
> > >library so far, so clearly your aims are different to mine.)
> > Could you explain why you aren't "very keen"?
> > Because the library isn't cast in concrete yet, knowing what
> > about it would be helpful.
> > If it is a matter of philosophy or aims rather that design
details, that is
> > important and helpful. We need to understand other views.
> Well, judging from the current partial implementation, it's partly
> it seems a bit too heavyweight -- something of a "kitchen sink"
> approach, trying to put every conceivable need into the API. I'd
> something a bit more spartan.
Care to elaborate. What's included is mostly the "core" threading
concepts. One of the only real exceptions I can think of is the
inclusion of recursive mutexes, but for C++ I think these are nearly
> It also seems to be following the pthreads architecture too closely
> my taste. It doesn't really "feel" like a designed-from-scratch C++
> library to me -- more like a thin OO wrapper around the pthreads
> and an attempt to emulate it on Windows. (I'm thinking in
> condition variables, a pthread-specific concept that I don't think
> belongs in a generic threading library.)
This is ironic. I'm the main developer on this (though I've gotten a
lot of input from others) and I'm a Win32 programmer with little
experience with pthreads. The only thing in the library that is
pthread-like instead of Win32-like is the condition variables, and
this happens to be a major lacking in the Win32 API. I don't know of
any serious MT programmers on the Win32 platform that haven't rolled
their own CV concepts because of this. The CV concept is _required_
to use a monitor pattern, which is one of the most flexible and easy
to use synchronization concept in OO programs.
In fact, I'd expect more people to accuse the design of being too
Win32 biased. For instance, the design of the Semaphore includes a
max setting and methods to increase the semaphore value by variable
amounts instead of one at a time. Another example is the design of
the thread class itself, which allows for multiple join() calls and
has no concept of detach(). I could continue with this list, but I
think you get my point.
> (When I have a bit more spare time, I'll polish up my own thread
> and post it somewhere for comparison.)
I'd be interested in seeing this, but it may be better for you to
point out specific things in the current implementation you'd do
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk