--- In Boost-Users@y..., "bill_kempf"
It sounds to me like what you want isn't a thread_group, but a thread_pool. All the thread_group is is a convenient way to manage the lifetime of multiple threads. A thread_pool, on the other
not only manages the lifetime but also the operation of the
With a thread_pool you simply add jobs and the thread_pool dispatches the job to a running thread if it's available, possibly spawns a new thread if there isn't an available thread, or adds the job to a queue to be processed by the next available thread. Elaborate thread
allow you to control things like the minimum and maximum number of threads that will be spawned to handle the jobs and how long a
hand, threads. pools thread
should be allowed to sit idle waiting for another job before it self terminates.
There are plans to add a thread_pool to Boost.Threads. In fact, a prototype is nearly ready to be uploaded to the main Boost list for comments (it's actually being worked on by someone else, but I've had some input on it).
Yes, it sounds exactly what I want. When will it be available?
This looks more like the classic example of the usage of thread_group, leaving me to wonder precisely what it is you want to accomplish. This code doesn't illustrate capping the number of "tasks", for instance. It's also a bit more complex then what I would have done, though it does work.
Ah well, it was just a test for the thread group anyway. It was just an idea of having some type of a life-cycle of a task, i.e. in this case setup, run and cleanup. Tasks would be forced to follow this strategy.
By the way, is there an operation in boost::thread to get the current thread id?
No, because not all platforms have any concept of thread id. I may add something along these lines soon, though it won't be precisely what you expect, I think. The ID won't be an integer, though it will be comparable.
That's right. I guess though, it will be enough if I could identify the thread_pools, mainly for logging I presume. Gunnar Olerud