sdussin said:
Thanx for the quick reply, William....
As a followup, I need to be able to get around the blocking of the thread_group while waiting, so I'm thinking of creating a new group class which contains a thread_group and exposes a join_current method to join on the currently running set of threads only.
This leads to a further question: If I'm running in a thread that was allocated as part of a thread_group (call it thread A) and I spawn a new thread (thread B) is the new thread (thread B) a member of the same thread_group as its parent (thread A) or is it not part of any thread group? (Assuming that I create the thread directly and not using thread_group.create_thread, of course :-))...
It's not part of any thread_group. It sounds like you're coming from a Java background? The thread_group isn't quite the same here as the ThreadGroup in Java. I've contemplated whether or not we should have a Java like thread_group semantic, but haven't really been swayed to it yet, and have kept our thread_group very simplistic. In fact, historically the only reason for boost::thread_group is to make it more convenient to spawn several threads in a loop and manage their lifetimes... and as such there's even been discussion of whether or not this concept should do any synchronization at all. -- William E. Kempf wekempf@cox.net