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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-26 20:24:23

At 08:20 PM 6/26/2001, Greg Colvin wrote:
 >From: Beman Dawes <bdawes_at_[hidden]>
 >> 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.
 >
 >Imagine a server that sits in a loop spawning threads to handle
 >incoming requests.  When the request is handled the thread is
 >done, at which time any resources used by the thread need to be
 >released, pronto.  So you need to create thread objects that will
 >magically disappear when they are done running.
 >
 >I started out to write a function to do this, and quickly began
 >to think it would be much easier for the thread class to provide
 >a utility for the purpose that returns shared_ptr<thread>.

Isn't that what detach() is for?  So after detach() has been called on a 
thread object, the underlying thread of execution is no long related to the 
thread object, and delete can be called on the thread object immediately.

If for some reason that won't work, it sounds like the thread function will 
have to own the thread object so it can destroy it before exiting.  So 
either the constructor which calls the thread function must pass a pointer 
(or auto_ptr<>), or there has to be a self() function which returns a 
pointer to the thread object.

For all the common usage idioms, we should provide an example if it is 
easy, and a helper if not.

--Beman