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
three
> > 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
out
> > threads the synchronization primitives are pointless, and with
out
> > 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
> implementations?
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.
Bill Kempf