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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-26 21:06:27

From: Beman Dawes <bdawes_at_[hidden]>
> 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.

So to do what I want I have to write

    thread* temp = new thread(handler);
    temp.detach();
    delete temp;

whereas with native code I would just do

    CreateThread(0,0,handler,0,0,0);

or in java

    new Thread(handler);

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

A harder example is keeping a list of all the running threads.
When I try actually writing such code I get confused real fast,
trying to be sure that the thread object has just the lifetime
I want.  But like I said, I've been infected by java, which
manages the life of the thread object automatically.

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

Yes.