www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Static Destructors called early

reply Loopback <elliott.darfink gmail.com> writes:
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?

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.

 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?
Jul 15 2011
parent Mike Parker <aldacron gmail.com> writes:
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).
Jul 16 2011