From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-03 13:36:08
--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: William Kempf <sirwillard_at_m...>
> > --- In boost_at_[hidden], Beman Dawes <beman_at_i...> wrote:
> > ...
> > > Rather than waiting for a single perfect library, would it move
> > things
> > > along faster if you separated the architecture into two or
> > sections
> > > (or levels, if that makes more sense), and then finalized a
> > submission for
> > > the most basic?
> > I'm not sure I follow you here. The seperations I see as a
> > possibility is for synchronization types and the thread
> > creation/manipulation type(s) to be seperated. However, this
> > seperation makes sense only as a stop gap approach for developers
> > only interested in making their libraries "thread safe". With
> > threads the synchronization primitives are pointless, and with
> > the synchronization primitives it's very difficult to use threads.
> Can't at least some of the thread synchronization primitives
> be implemented so that they work no matter how the threading
> is done?
All of them are implemented independent of the thread type(s). Sorry
if I caused confusion on this point.
> If not, can they be parameterized so that the user of a Boost
> library requiring synchronization can provide their own
I see no benefit in this type of approach. It would only lead
to "reinvention of the wheel" by developers.
> We should not require users to use the Boost threading library
> when they need thread safety.
Why not? They need not use (nor should they) the thread type(s) in
this case, but the concepts are so dependent on each other that I
don't see a benefit in seperating them into seperate libraries, while
it seems the wrong thing to do.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk