Wrt. threadlocal by default: shared module constructors

Brad Roberts braddr at bellevue.puremagic.com
Wed May 13 17:44:43 PDT 2009


On Thu, 14 May 2009, Lionello Lunesu wrote:

> Denis Koroskin wrote:
> > On Wed, 13 May 2009 16:50:25 +0400, downs <default_357-line at yahoo.de> wrote:
> > 
> > > So .. how will the threadlocal global variables be initialized?
> > > 
> > > Obviously, they can't be initialized in the static constructor, since
> > > that is only run once.
> > > 
> > > But if the static constructors are run on every new thread, what about
> > > the shared variables that only need to be initialized once?
> > > 
> > > For these reasons, I propose two changes:
> > > 
> > > 1) Module constructors are run at thread creation
> > > 
> > > 2) the introduction of _shared module constructors_, who are run before
> > > module constructors, at program startup, to initialize the global shared
> > > variables.
> > > 
> > > I don't see any other way to handle these issues.
> > > 
> > > Feedback appreciated.
> > 
> > static this() {}
> > static shared this() {}
> > static shared ~this() {}
> > static ~this() {}
> > 
> > (in that order)
> > 
> > ?
> 
> I think he meant shared first/last:
> 
> static shared this(){}
> static this(){}//main thread
> static this(){}//thread x
> ...
> static ~this() {}//thread x
> static ~this() {}// main thread
> static shared ~this() {}
> 
> ...which is (as Kagamin suggested) similar to they way DLLs are (de)inited on
> Windows.
> 
> vote++ by the way.
> 
> L.

An interesting side effect of these changes is that thread startup cost is 
going to increase.  Yet more reasons to avoid globals and global 
initialization.

-- Brad



More information about the Digitalmars-d mailing list