Static Destructors called early

[Mike Parker]

On 7/16/2011 6:11 AM, Loopback wrote:
> Hi!
>
> I'm having a pretty big mess just because my static destructors are
> called before my non-static destructors. Now my question is; is this
> related only to win32 applications where one uses runtime.terminate?

You can never rely on when or if a destructor will be called unless you 
call them manually via delete (or, I suppose these days, clear()). For 
releasing system resources, you should handle it manually before the app 
exits.

>
> The problem is that I am using external libraries, and in one of these
> cases you initialize the library and later on release it. I initialize
> and release the library in static de-/constructors. The external library
> I use is a sound library (FMOD). I have a sound class which uses library
> functions which in turn needs the library to be *initialized* and not
> *released*, when called. In the sound class, I release the sound file
> in the destructor, but this fails because the static destructor (which
> releases the library itself) has already been called, and therefore all
> library function calls are invalid.
>
> Are there any workarounds or solutions? And is it absolutely necessary
> to use the runtime initialize and terminate functions, since it works
> without any problems in a normal (non-win32) application.

If you look in the source of your DMD2 installation directory and find 
the file src/druntime/src/rt/dmain2.d, you'll find the following function:

extern (C) int main(int argc, char** argv)

This is the normal application entry point when you use a D-style main. 
It handles runtime initialization/termination and calls your 
application's D-style main. However, if you use a WinMain function, that 
becomes the new entry point for the application. That's just the way 
Windows works. This means that the function in dmain2.d is never called 
and you have to handle the runtime's lifecycle yourself.

If you want to have a Windows application without a console popping up 
and without using WinMain, add this to your DMD command line:

-L/SUBSYSTEM:windows:5

If you need to support Windows 9x, replace the 5 with a 4.

>
>  From what I know, static de-/constructors are called when the main
> function exits, but does it occur when the runtime, terminates when
> using a win32 application?

It's the runtime that calls the static desconstructors during 
termination. Looking in source/druntime/src/core/runtime.d, you'll see 
that runtime.terminate calls the extern function rt_term. The rt_term 
function is implemented in dmain2.d, which I mentioned above. Looking 
there, you'll see the following:

_moduleTlsDtor();
thread_joinAll();
_d_isHalting = true;
_moduleDtor();
gc_term();

Notice the fourth line, _moduleDtor(). That's where all static module 
and class destructors are called. Then after that, the last line calls 
gc_term. This is where the class destructors are called. And that's why 
you are seeing the problem you have.

It doesn't matter if you use WinMain or main, this problem will always 
happen because of the order in which things are cleaned up. The solution 
is to never, ever, rely on order of destruction. All you can say 
generally is that static destructors will be run before the gc is 
terminated and that class destructors might be called at any time before 
(during the course of the program) or after (during temination).