On Tue, 2006-12-19 at 10:40 -0500, Stuart A. Malone wrote:

However, I don't think that join_all() is an option in this case, because I need to be inside a Mac event loop in order to receive the messages that will launch the additional threads. Since join_all() would block until the existing threads had completed, I would never receive the events telling me that I needed to launch additional threads.

[Diverting to boost-users because this regards boost-threads usage, not development]. You might find the attached code interesting as an example of how things could be structured. The loop in main() spends most of it's time blocked on a getc call (which would presumably correspond to some sort of event pump in your app), but a separate thread (the "master") manages a pool of worker threads (initially 1; another one is added each time you hit return on the console). Each thread runs for 10s printing '.' every second then terminates; if the worker count reaches zero the master terminates too. To be concise the code uses volatile bools to communicate state between threads; in any sort of real code these would probably be mutex-protected structures or std::deques. The real key to the whole thing is the boost::condition, which allows the master thread to notice both keypresses from main() and completing workers. Note there's no boost::barriers to be seen. [Attached code compiles with gcc threadmaster.cpp -o threadmaster \ -g -pthread -lboost_thread -lpthread on Debian Sarge with appropriate boost packages installed]. Tim