I have implemented my own thread class based on boost::threads almost two years ago and it does all the things that you guys are talking about here. Initially I attempted to implemented this using boost::threadgroups but I soon relised that boost::threadgroups was more or less unusable (in boost 1.30.0). My abstract Thread class runs under Windows, Linux (RH9) and HP-UX. Some of the features the class implements: - parent, child and dependent threads (or any combination of these) - framework supports pause/resume/stop requests and these requests are automatically propagated to child threads - timer threads - notify message which allows you to send customised events to a thread The downside is: - I don't have a lightweight example and the class suits my project - Documentation - what documentation? :( - There is quite a bit of overhead per thread object If anyone is interested, I'm happy to provide the code, just send an e-mail. I'd be interested to have a look at your code Martin if you don't mind. Pete
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/bo> ost-users