From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-11-11 13:21:45
Yeah, it's the same concept. I had failed to distinguish thread_pool versus
Hopefully, adding the timeout and growing logic does not sacrifice the
efficiency of the pool when it is full/has plenty to work on.
"William E. Kempf" <wekempf_at_[hidden]> wrote in message
> Eric Woodruff said:
> > William,
> > I'm not sure. I haven't been following the development branch, and don't
> > know exactly how to access it.
> $> cvs co -r thread_development boost
> would check out the thread_development branch. Tweak as needed for your
> > I called this class a function queue
> > based on what I saw of the currently released boost::thread::thread_pool
> > which was merely a collection of various threads that provided a grouped
> > join.
> I think you're talking about boost::thread::thread_group here. The
> boost::thread::thread_pool in the thread_development branch sounds like
> your "function queue", unless I'm misunderstanding something from your
> short description.
> > I needed to be abstracted from the thread itself. Thus, thread was
> > not a good choice in the class's name.
> I'm not sure I follow this, but here's a short example of using a
> int min_threads=3;
> int max_threads=10;
> int timeout=10; // seconds
> boost::thread_pool pool(max_threads, min_threads, timeout);
> The number of threads that will be used to dispatch the queued function
> objects will expand and contract between min_threads and max_threads, with
> idle threads waiting for the specified timeout before terminating if there
> are more than min_threads available.
> The user never directly accesses a thread in a thread_pool. He only adds
> function objects to a queue on which the pooled threads will work.
> William E. Kempf
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk