From: williamkempf_at_[hidden]
Date: 2001-06-27 15:58:45
--- In boost_at_y..., Jeremy Siek <jsiek_at_r...> wrote:
>
> It seems to me that there are two main thread life-time models
> that need to be supported:
>
> 1) the new thread has a shorter lifetime than the parent thread,
> and the parent thread waits at some point for the new thread
> to finish (joins it).
>
> 2) the new thread may have a longer lifetime than the parent thread
> (and needs to be detached).
Almost. A detached() thread won't necessarilly last longer than the
parent thread. We just don't care about its lifetime. If
the "parent" thread is the "main" thread, the "child" thread simply
can't outlive its "parent".
> I think we need explicit mechanisms for dealing with both of these
models
> (and not just pick detach() or join() as the default action for a
thread
> object's destructor)
A different way to look at the problem. At least worth considering.
> For 1) the approach of having a scope object that starts the thread
on
> construction and does a join in the destructor would probably work.
This
> ensures that the user doesn't forget to join, and makes sure that
the
> thread id goes away
>
> For 2) a create_detached_thread() function would do nicely... have
the
> thread be detached from the start. It would be a good idea to have a
> different thread id type for detached threads, and to *not* provide
a join
> or cancel function for this type, since detached threads cannot be
joined
> or cancelled, and it would be nice to express this in the type
system. The
> thread id in this case would *not* use a scoped object/destructor
to do
> anything, since the lifetime of this thread has nothing to do with
the
> parent, and in the creation we've already set the thread to be
detached.
> I'm almost tempted to say that create_detached_thread() should not
return
> any thread id... there is very little one can do with a detached
thread
> from the parent thread.
That depends on your definition of detached. It's quite possible
that I'll want to manage the thread's priority even if I don't care
to manage its lifetime, for instance.
> Are there other life-time models that need to be considered?
If you strictly look at it as a life-time model, then no, there
couldn't be. Either the thread must have a life-time shorter than
it's parent, or it doesn't.
BTW, I dislike using the term "parent" here. It's quite possible
that a thread other than the creator will be the thread that
determines the life-time requirements. In other words, the
term "owner" is better, since the ownership can be passed to another
thread.
Bill Kempf