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