Re: Boost.Threads - thread_desc concept

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