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.