Martin Pasdzierny wrote:
Hi Boost::Thread users (developers)
During the past months I had to create a portable thread management shell around boost::threads to allow a simple thread management.
The idea was to (implicitly) put each thread into a hierarchy (just like forked processes but with more features than boost::threadgroup offers). These threads now share a global structure to allow global access to their control interface (mainly a 'stop!' flag). Additionally I wanted to make threads requested to stop (triggered by themselves or from outside) implicitly stop their children and finally remove themselves from the thread management structures.
It took me some time to make this approach a stable implementation (would have been much easier if boost::threads exposed their internal and platform-specific id).
I think the idea of hierarchially organized threads is quite common and wonder how it could be *elegantly* designed using boost::threads.
Interestingly this question pops up rather seldom. Nevertheless I've run into a similar proplem also related to graceful stopping a thread, which I am currently working on. Remarkably a question posted to c.p.threads about examples or advices of how to stop a thread gracefully (using pthreads) got no answers at all. At least with boost threads there is nothing such as a "thread ID" concept, i.e. you cannot (from another thread) control it by native means. N.B.: The thread* is not usable as an ID in this respect, since there might be two different pointers refering to the same thread. (at least in principle) I am considering two possible implementations: 1) pass a "control object" as parameter to the thread function. 2) derive a custom thread from boost::thread that exposes a control function. (and store a pointer to it in TLS strorage, so that it can be seen from inside the thread.) Either way the main problem that needs to be solved is of how to control the lifetime of this control structure. Keep in mind that the thread structure might have been deleted before the thread ends. The opposite also is possible and thus has to be considered as well. The concepts needed are related to the problem of breaking out of threads that are currently blocked. I have heard from Aaron, that he is about to propose a solution to this. Perhaps the concepts he is suggesting can be used in this broader context too? Roland