Boost logo

Boost :

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);
    delete temp;

whereas with native code I would just do


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at