Re: [boost] Re: Boost.Threads - Final Design Decisions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-21 14:25:03

From: <williamkempf_at_[hidden]>
> --- 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.

> > 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."

--
Peter Dimov
Multi Media Ltd.