Re: Boost.Threads - name of the "thread" type

From: williamkempf_at_[hidden]
Date: 2001-06-22 11:15:59

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > ...
> > > OK.  In java the idiom  (new MyThread()).start() is pretty 
common.
> > 
> > Such an idiom would be a hardship in C++ with out a GC.  I've 
also 
> > seen many Java thread derived classes that call start() in their 
> > constructors... which to me shows how awkward the two phased 
> > construction is, even in Java.
> 
> In Beman's interface the above idiom is just
> 
>     thread::create(function)
> 
> Note that the return value is ignored.  Thus my take that the
> lifetime of the thread object needs to be managed automatically.
> GC is not needed as a simple counter will do.

That's the pattern used with the existing interface.  Beman's 
suggestion doesn't work this way, since a raw pointer is returned 
with the user having to manage the lifetime, while calling delete 
destroys the thread.  However, you and I have both suggested a 
combination of the two designs resulting in two concepts instead of 
one, which would work exactly as you suggest here.

> From: <williamkempf_at_h...>
> > ...
> > > Another way is to have copyable thread_ref objects that
> > > allocate and reference-count a non-copyable thread object
> > > behind the scenes, e.g. 
> > ...
> > The J/Thread package takes this approach.  It's Thread type is a 
> > proper representation of the thread state while the static create
() 
> > method returns a ThreadHandle referencing this object.  The 
actual 
> > Thread object remains as long as a ThreadHandle continues to 
> > reference it or the thread itself continues to execute.  Deleting 
the 
> > thread object directly is undefined behavior.  This design is 
also 
> > unusual when compared to existing standard types, but it may be 
the 
> > proper compromise here.
> 
> It may be unusual, but threads are unusually dynamic objects, and
> the J/Thread approach matches my intuitions.  But perhaps I have
> been infected by java.

Possibly.  That's why I said it *may* be the proper compromise.  I'm 
also imagining a thread type that was noncopyable, that spawned the 
actual thread of execution in the constructor, and that did a join() 
on destruction unless a detach() method had been called in between.  
This would be more in fashion with C++ design, though it makes it at 
least slightly more complicated to share management responsibilities 
between various objects, which is a common task.  It also makes some 
things difficult or impossible to do.  For instance, a self() method 
no longer is viable or appropriate, and spawning several threads in a 
loop becomes more complicated.

Bill Kempf