"Rob Stewart" <stewart@sig.com> wrote in message news:200406081404.i58E49L27521@lawrencewelk.systems.susq.com...
From: "Johan Nilsson" <johan.nilsson@esrange.ssc.se>
"Malcolm Noyes" <boost@alchemise.com> wrote in message
IIRC, the complexity arises when you start to consider global scope thread specific variables in different translation units, together with the possibility that threads can be started before 'main' and waited on, i.e. joined, after 'main has completed. Ah, I see the
Do you really want to account for the creation and joining of threads outside of main()? I'm no MT expert, but I recall learning that one should avoid creating threads prior to main. It makes statics and even main() difficult to write. Isn't that correct? If so, should Boost.Thread really account for bad designs?
Well, you replied to my posting but to _Malcolms_ text ... whatever. I think you actually need to account for this and that such a design is not neccessarily bad. As an example, consider a singleton utilizing a thread pool created at object creation time (which might occur anytime in the program). When the singleton is destroyed, it wants its workers to exit. To make sure the threads have a possibility to do a _controlled_ shutdown, the singleton signals the threads that they should terminate, and then waits for them to exit (by using e.g. join) before returning from the destructor. To be on the safe side though, it would be preferable to use a timed join ... there's always the possibility that one of the worker threads might hang causing the entire program to stop at exit time. [Before embarking on the singletons-are-also-bad-design trail, remember that there are exceptions to the rule.] // Johan