Re: Boost.Threads - Final Design Decisions

From: williamkempf_at_[hidden]
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" 
doesn't
> > seem to
> > > > apply, so I don't know what you mean by that.  In any event, 
with
> > > > std::fstream "there can be many such objects" and they 
are "first
> > class
> > > > citizens".  I truly don't see any problem here.
> > >
> > > The default-constructed thread objects are more constrained in 
their
> > > 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, 
please"? I
> 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 
object
> > is
> > > compare it for (in)equality.
> >
> > Currently.  As we add functionality to boost::thread, such as 
being
> > able to change it's priority, this will no longer be the case.  
The
> > only restriction is calls to join.
> 
> You're thinking in terms of an expanded design that I know nothing 
about; I
> 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 
no longer
> "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.

Bill Kempf