Re: [boost] Re: Boost.Threads - thread_desc concept

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-06-27 15:32:39

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).

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)

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.

Are there other life-time models that need to be considered?

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate, IU B'ton          email: jsiek_at_[hidden]
 Summer Manager, AT&T Research      phone: [phone]
----------------------------------------------------------------------