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

From: Rainer Deyke (root_at_[hidden])
Date: 2001-08-18 12:27:15

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, August 18, 2001 10:52 AM
Subject: Re: [boost] Boost.Threads - Final Design Decisions

> From: "Alexander Terekhov" <terekhov_at_[hidden]>
> > > A noncopyable thread object _is_ a perfect fit
> > > for the thread concept if you can guarantee that
> > > there is one to one correspondence between the actual
> > > threads and the C++ thread objects.
> >
> > agree.
> >
> > > Such a design is possible:
> > >
> > > thread & create(F f);
> > > thread & current();
> > >
> > > [where current() called from within 'f' would
> > > return a reference to the same thread object as
> > > create().]
> >
> > i think that the following is also possible:
> >
> > thread mythread( f );
> >
> > [where current() called from within 'f' would
> > return a reference to mythread thread object]
>
> It is, but it has its problems. The important question is, who controls
the
> thread object lifetime; is it the library, or the user.
>
> When the library manages the lifetime of the thread object, we have the
> design I outlined, where create() and current() return a thread &, or
> shared_ptr<thread>, or thread::ref. The thread object lives until the
thread
> terminates (in the thread& case)

That would be bad.  It means you can't really do anything with a thread
object except within the thread itself.

thread& t = create(f);
do_something_with(t); // Oops!  The thread has already terminated,
                      //  invalidating 't'.

> or until the thread terminates and there
> are no more references to the object.
>
> When the user explicitly creates thread objects, as in the current design
> and your example, current() can't return a reference since the thread
object
> may have already been destroyed (but the actual thread still runs.) The
best
> you can do is
>
> thread * current();
>
> where current() returns 0 when the thread object has been destroyed.

There is another possibility: 'thread::~thread' blocks until the thread has
actually terminated.  This means that for every thread, there always exists
a thread object (but not necessarily vice versa).  I'm not sure how useful
this would be in practice.

--
Rainer Deyke (root_at_[hidden])
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor