[M3devel] order of module initialization...

[j k]

Reminds me of C++ globals with constructors.

The solution is to avoid initialization.

Do everything "on demand" and hide all state behind functions.
   and then "on demand" needs to be thread safe, so there is a small 
bootstrapping problem -- basically the only initialization you should do, 
speaking in Win32-ese, is a few calls to InitializeCriticalSection and maybe 
TlsAlloc and maybe HeapAlloc, but nothing "cross module", or more 
accurately, nothing "in the same layer", if you have a dependency graph, 
only "to a lower layer", which InitializeCritical/TlsAlloc nearly always are 
(unless you are working on ntdll.dll, but even then.. :) ) If you don't have 
a strict layered design, or can't capture what it is and analyze statically, 
again, just restricting yourself to InitializeCriticalSection/TlsAlloc is an 
easy way to be correct.

And even then, you can often avoid the critical sections via something like 
InterlockedCompareExchangePointer, even implement spin locks for this rare 
code. (Hand written spin locks are generally to be avoided since the kernel 
won't know about them and you won't schedule efficiently, whereas with 
EnterCriticalSection, if there is contention, the kernel has a hint what is 
going on and can schedule better).

Don't have any "public global data",  unless, and I don't know if this 
applies in Modula-3, unless it is "constant initialized", which I'm not sure 
is well defined in C++ or not. I do believe it is well defined in C..except 
dynamic linking I think screws that up to.

(pardon the Win32-centricity; I'm sure the principles apply more broadly)

Ok, in C++ and in Modula-3, there are maybe better answers.
In C++, globals within a source file are guaranteed to be initialized in the 
order they occur in the file.
But the order of files is not defined.
There is a documented trick..potentially very inefficient..that I don't have 
the patience to describe here.. "the iostream counter trick"... this I don't 
think has an analog in Modula-3, but sure.
Stroupstroup's Design and Evolution book documents it.

- Jay


>From: Dragiša Durić <dragisha at m3w.org>
>To: "M3 Developers' Mailing List" <m3devel at elegosoft.com>
>Subject: [M3devel] order of module initialization...
>Date: Fri, 20 Apr 2007 21:36:25 +0200
>
>I remember debugging this first time we tried to migrate to CM3... And
>then we solved it, for current CM3 and current version of our software,
>mentioning some imported module in EXPORTS clause... at the moment, this
>linked these modules in initialization chain  and it worked ok... Right
>now, it does not.
>
>Module XLBuiltin is one imported regularly, and XLModuleUDP (for
>example) both EXPORTS and IMPORTs XLBuiltin. It is linked and starts to
>initialize, but _before_ XLBuiltin... And, fails. Something is NIL @
>wrong moment...
>
>What would be solution for this?
>
>dd
>--
>Dragiša Durić <dragisha at m3w.org>
>
>_______________________________________________
>M3devel mailing list
>M3devel at elegosoft.com
>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

_________________________________________________________________
Download Messenger. Join the i’m Initiative. Help make a difference today. 
http://im.live.com/messenger/im/home/?source=TAGHM_APR07