Wrong order of shared static dtors

[Steven Schveighoffer via Digitalmars-d]

On 11/10/14 9:57 AM, Marco Leise wrote:
> I know the runtime is supposed to work it all out, call
> thread module dtors, then shared dtors and then terminate.
>
> But now I have a case where it is broken and I don't know if
> we expect the runtime to figure it out, especially when it
> comes to separate compilation and such. Basically on one end
> I have a singleton template that uses a `shared static ~this()`
> to destroy the object. On the other end I have a global list
> of reference counted resources, also heavily templated and
> relying on a `shared static ~this()` to free the memory
> associated with the ref counts etc.
> When I build something new from these parts, like a singleton
> object that contains on of these ref counted resources, the
> runtime is unable to figure out that it has to destroy the
> singleton (and its resource with it), before it can call the
> destructor of the resource list. For now I just wrote
> `import Lib.Sys.Resource;` into the singleton destructor
> (i.e. every singleton imports it, whether it needs it or not),
> but that doesn't scale obviously.
>
> Should the runtime be able to reliably figure out even such
> tough cases? The alternative, disallowing static dtors in
> templates isn't appealing.
>
> Out of curiosity: What module do templated static dtors belong
> to anyways. And how does that effect when they are called?
>

I don't know about your specific issue. But I do know how the runtime 
calls static ctors/dtors because I rewrote that part a few years ago.

First, any ctors/dtors in a specific module are called in the order they 
appear in the file.

Second, the compiler records 3 things about a module:
1. Is it a standalone module? That is, does it not import any other modules.
2. If not, what modules does it import.
3. Does it have any dtors or ctors (it has a flag for each kind)

When run, the runtime uses this information to build a graph of the 
ordering to call the static ctors. If it detects any cycles in that 
graph, where module A imports directly or indirectly module B, and 
module B imports directly or indirectly module A, and both of them have 
the *same kind* of static ctor or dtor, then it errors and refuses to 
run the program (I'm sure all of you have seen this error).

Now, if that doesn't happen, it has a list of modules, of what imports 
whatever else. And it can call the static ctors in the order of that 
graph making sure dependent modules are constructed first. It does this 
separately for shared and unshared ctors/dtors. Standalone modules are 
called first, and are not included in the search for cycles.

On program/thread termination, it calls the dtors in the opposite order.

Two things that it CANNOT detect:

1. If you circumvent the module system to call functions in static 
ctor/dtors using extern(C).
2. If you establish any dependencies during runtime, such as pushing 
into module A's global array a reference to a module B global object, 
without module A or B importing each other. It won't know to call module 
A's dtor first.

I'm guessing the latter is what you are having issues with.

-Steve