On 3/4/15 4:15 PM, rumbu wrote:
On Wednesday, 4 March 2015 at 16:08:00 UTC, Steven Schveighoffer wrote:
curiously not listed? That doesn't make any sense. If there is not a
cycle in the listed modules, where at least 2 modules have a static
ctor or static dtor, then there is a bug in the cycle detection code.
Source code is available here: https://github.com/rumbu13/sharp
The runtime error chain was "system.globalization -> internals.locale ->
system.runtime.interopservices -> system.io ->
system.globalization
Three of these modules import "internals.resources" containing a static
constructor. The static dtor is in system.runtime.interopservices.
I'll take a look. importing a module that has static ctor/dtor doesn't
count, it must be in the module itself to be part of the cycle.
Clearly, the above is not an issue, but at the moment, the code treats
having a ctor and having a dtor as the same thing. How to fix it? I'm
not exactly sure, you need to have the modules sorted according to
ctor and also according to dtor. The runtime is supposed to run dtors
in reverse order from ctor calls, and I think we should not break
that. But there is definitely room to allow for reordering when ctors
are not affected.
I'll have to think about it some more.
Why bother? I'll leave this to the programmer, he can take full
responsibility to not mess up module ctors/dtors. I remember the old
Delphi days where this was assumed from the start: initialization and
finalization order of execution (equivalent of static ctor/dtor) were
not guaranteed. It was better to obtain an AccessViolation or a
StackOverflow and correct the circular reference, instead of a NEVER
running executable.
Well, 1) because we can fix it, and it's the correct thing to do, and 2)
because it's an interesting problem (I remember when I fixed the old
cycle detection code, which was buggy and just printed "cycle detected"
or some such nonsense, it was a very interesting difficult problem to
solve).
-Steve
