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