On 3/3/15 4:24 PM, rumbu wrote:
On Tuesday, 3 March 2015 at 18:55:49 UTC, Steven Schveighoffer wrote:


Only one of the listed modules has a static contructor
(system.globalization) and that constructor doesn't use any information
from other modules.

It's a complex problem. Because we don't control the linker, we cannot
establish an order of execution for the module system. It must be a
directed acyclic graph. Although, cycles are allowed that only involve
a single module with ctor/dtors, or with no ctor/dtors. But we have to
detect it at runtime during startup.

two of those modules should have static ctor or dtor (they may have
either to cause the error).

The message is not too helpful, I have no clue where to start searching
for the error source, the source code has more than 25k LOC. In fact, I
don't believe this error is true, since I have only two non-linked
modules with static contructors.

Just look for "static this" and "static ~this" inside those files
identified.


-Steve

One of the listed modules had a ctor. Another one - curiously - not
listed in the cyclic error - had a static dtor, and this module was
imported by two of them.

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.


Anyway, reduced case scenario:

module a;
import b;
static this();
-----
module b;
import a;
static ~this();

As I supposed, this is a false error, the order of execution seems very
clear to me, but not for the runtime. Even if I have two ctors, I think
it's better to relax this rule, maybe the constructors are not dependent
one of each other to have cyclic errors. In my case, one of the
constructors loads some resources bound to the executable and the
destructor is simply a winapi call to CoUninitialize, totally unrelated.



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.

-Steve

Reply via email to