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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-26 18:53:28

At 07:36 PM 6/26/2001, Greg Colvin wrote:

 >From: John Max Skaller <skaller_at_[hidden]>
 >> williamkempf_at_[hidden] wrote:
 >> >
 >> >
 >> > The first impediment is that it's a very common practice to copy
 >> > the "thread" (actually the descriptor, as you pointed out) in order
 >> > to allow some other piece of the program manage the thread.  For
 >> > instance, a thread pool is going to have to store the threads in some
 >> > sort of data structure.  This design requires all such uses to be
 >> > dynamically allocated via new, which complicates the management
 >> > though it can be lessened by immediately placing them in a smart
 >> > pointer.
 >>
 >> I'd say that simplifies the design by factoring the
 >> management and owenership of the thread object out, and leaving
 >> the thread object to just deal with thread related things.
 >
 >I think I like it, but I'm not seeing an easy way to
 >create a thread object that goes away when the thread
 >exits.

Isn't this similar to a file?  If a file gets closed() before the file 
object is destroyed, the file object is in a "closed" state until the 
destructor runs.

If the function invoked by the thread constructor exits or the thread of 
execution dies in some other way, then the thread object is logically in a 
"closed" state.

--Beman