Date: 2001-08-21 15:16:31
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > From: "William Kempf" <williamkempf_at_h...>
> > > > (1) I totally don't follow this. The term "surrogate"
> > seem to
> > > > apply, so I don't know what you mean by that. In any event,
> > > > std::fstream "there can be many such objects" and they
> > class
> > > > citizens". I truly don't see any problem here.
> > >
> > > The default-constructed thread objects are more constrained in
> > > functionality than the "primary" thread object - by which I mean
> > the object
> > > that started the thread.
> > Ahhh. Well, the only real restriction is that you can't call join.
> > I'm not sure that this is that big of an issue.
> Well; you're in thread A. How do you tell thread B: "Join me,
> don't know whether this qualifies as big or not.
How do you tell it? With a condition variable. But I think your
real question is "how does B join A". If B didn't create A then he
probably doesn't "join" A. He may want to wait for A to finish doing
some processing, but again, that's what condition variables are for.
A "join" is more then just a wait for completion.
> > > The only thing you can do with a default-constructed thread
> > is
> > > compare it for (in)equality.
> > Currently. As we add functionality to boost::thread, such as
> > able to change it's priority, this will no longer be the case.
> > only restriction is calls to join.
> You're thinking in terms of an expanded design that I know nothing
> talk about the current semantics, where the only thing you can do
is join. I
> agree that in a future design where 'join' is only a fraction of the
> supported functionality the default-constructed thread objects are
> "second class citizens."
I'm not sure I agree with that reasoning, but I'm not sure it
matters. The big question is whether or not the current design makes
some things more difficult to accomplish then they should be.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk