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

From: scott (scottw_at_[hidden])
Date: 2004-06-08 15:11:41

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Michael Glassford
> Sent: Wednesday, June 09, 2004 2:32 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Thread lib (good reason for static)

[snip]

> > 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?
> > 
> 
> The biggest problem with this is that global static objects are 
> initialized before main(). Is it necessarily a bad thing for the 
> constructor of such an object to create a thread?

Assume use of a technique like the following (think this has been
presented as "object shim"?);

T &
anastasia()
{
        static T *p = new T;
        return *p;
}

as a means of dealing with global construction issue, i.e. instead
of expressions like "anastasia.data_member" the usage is
"anastasia().data_member". Also assume that some of these global
objects (i.e. shims) deploy mutexes for MT reasons. What happens
when there is more that one thread running around making calls
to shims? Instantiation of the global itself becomes an MT issue.

It is a specific example, but it is unfortunate to lose the utility
of a technique that is current preference for another curly issue.

Cheers,
Scott