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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-22 10:39:01

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

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