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.

On Wed, 13 May 2009 16:50:25 +0400, downs <default_357-line@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)

?

In windows PROCESS_ATTACH is handles before THREAD_ATTACH.

Denis Koroskin wrote:
> On Wed, 13 May 2009 16:50:25 +0400, downs <default_357-line@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.

On Thu, 14 May 2009, Lionello Lunesu wrote:

> Denis Koroskin wrote:
> > On Wed, 13 May 2009 16:50:25 +0400, downs <default_357-line@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

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.

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

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

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.