www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Wrt. threadlocal by default: shared module constructors

reply downs <default_357-line yahoo.de> writes:
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.
May 13 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
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)

?
May 13 2009
next sibling parent Kagamin <spam here.lot> writes:
In windows PROCESS_ATTACH is handles before THREAD_ATTACH.
May 13 2009
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
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.
May 13 2009
parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
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
May 13 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
May 13 2009
next sibling parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
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
May 13 2009
parent Derek Parnell <derek psych.ward> writes:
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
May 13 2009
prev sibling parent downs <default_357-line yahoo.de> writes:
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.
May 15 2009