Re: Wrt. threadlocal by default: shared module constructors
Christopher Wright wrote: > Brad Roberts wrote: >> 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 > > It'll further promote use of threadpools. This isn't terribly safe > because the globals for that thread are left in some arbitrary state -- > yet more reason to avoid globals. Introspection would solve this. Just define a function initThread(), then use introspection to iterate over the module graph, find all static functions by that name, and call them whenever a thread needs to be cleaned up.
Re: Wrt. threadlocal by default: shared module constructors
On Wed, 13 May 2009 18:31:57 -0700, Brad Roberts wrote: > Which argues for the globals to be immutable, so the cost goes away and > we're back where we started. :) Which actually brings back memories of my COBOL and IBM/360 assembler days. The mantra then was "everything must be reenterant" so the norm was that mutable globals were seen as evil. However, later I worked at a place where assembler abuse was taken to the artform level - self-modifying code was encouraged! -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Wrt. threadlocal by default: shared module constructors
On Wed, 13 May 2009, Christopher Wright wrote: > Brad Roberts wrote: > > 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 > > It'll further promote use of threadpools. This isn't terribly safe because the > globals for that thread are left in some arbitrary state -- yet more reason to > avoid globals. Which argues for the globals to be immutable, so the cost goes away and we're back where we started. :) (this is fun.. who's next?) -- Brad
Re: Wrt. threadlocal by default: shared module constructors
Brad Roberts wrote: 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 It'll further promote use of threadpools. This isn't terribly safe because the globals for that thread are left in some arbitrary state -- yet more reason to avoid globals.
Re: Wrt. threadlocal by default: shared module constructors
On Thu, 14 May 2009, Lionello Lunesu wrote:
> Denis Koroskin wrote:
> > On Wed, 13 May 2009 16:50:25 +0400, downs 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
Re: Wrt. threadlocal by default: shared module constructors
Denis Koroskin wrote:
On Wed, 13 May 2009 16:50:25 +0400, downs 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.
Re: Wrt. threadlocal by default: shared module constructors
In windows PROCESS_ATTACH is handles before THREAD_ATTACH.
Re: Wrt. threadlocal by default: shared module constructors
On Wed, 13 May 2009 16:50:25 +0400, downs 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)
?
Wrt. threadlocal by default: shared module constructors
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.
