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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-26 19:20:57

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