Boost logo

Boost :

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


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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at