From: Milutin Jovanovic (miki_at_[hidden])
Date: 2001-01-04 09:59:43
----- Original Message -----
> > > > > 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.
> Good, thanks.
I am suffering extreme time shortage, so I have kept my mouth closed for a
very long time. However, at this stage I have to ask the following. What is
the aim of the threading support we are planning? Is it:
a) rudimentary support for the multi-threading promitives
b) provinding a complete set of sophisticated objects to support
A) means providing very basic mutex, conditional variables, thread, all
independent of each other. B) would provide these and more, and allow more
sophisticated uses like waiting for multiple conditions, prioritised
mutexes/CV's, even allowing to wait on socket (and any other convinient
condition) together with threading primitives.
I for one have no preference on the choice. But every time people say "mutex
should be independent of thread" or similar, my question pops up in my mind
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk