[boost] Re: Re: Thread lib (good reason for static)

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-06-09 02:09:25

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200406081404.i58E49L27521_at_lawrencewelk.systems.susq.com...
> From: "Johan Nilsson" <johan.nilsson_at_[hidden]>
> > "Malcolm Noyes" <boost_at_[hidden]> 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