static object destruction in shared library

Jeff Greif
Fri Dec 31 20:54:00 GMT 1999


I was not complaining about gcc.  I was not reporting a bug in gcc.
I was not asking you to fix my code -- something unexpected happened
in my first version but I found a solution for myself.  Somehow I failed
to convey my intentions properly.  The original thread dealt with using
atexit to handle destruction of static variables defined in the body of
functions.  I was only trying to point out that this technique had
problems because atexit had platform-dependent quirks when dlls were used.

In particular, on Windows NT, if atexit is used in a DLL and the DLL is
explicitly unloaded in the code, the atexit-registered function will run
during DLL unload
at a completely different (much later) stage of the process shutdown than
an atexit function registered by the main executable.
The attempt was to provide an example from my experience.  I don't think I
to be dressed down for this attempt to provide a little information to the
But thanks for the suggestions.


Mike Stump wrote:

> > Date: Thu, 02 Dec 1999 00:16:12 -0800
> > From: Jeff Greif <>
> > 2.  I agree about having requirements like 'thou shalt not unmap...'
> > if they are documented.  The problems I ran into were not.  I had to
> > read the source of the Win32 runtime library to find out what order
> > things occurred in (and also that atexit worked differently in
> > DLLs!).
> I am sorry providers of your software didn't document stuff for you,
> you need to take it up with them, not me.
> > Here is a piece of code that represents the problem
> You appear to think that the object owns the thread.  The object is
> part of a dll and you expect that the thread won't be killed before
> the object is killed.  This expectation runs afoul of the environment
> presented to you on NT.  Either, you didn't ask or arrange for this to
> be the case (you'll have to check the documentation of the software
> you're using), or, it just doesn't provide that model that you want.
> In any event, it doesn't sound like a bug in the compiler.  It sounds
> like you just don't like the model provided by the software you use.
> If the software won't postpone thread termination, then you will have
> to arrange to put in a forwarder from something that can be arranged
> to be killed before the threads for the group, so that this fowarder
> can arrange to kill those things that you want killed before the
> threads die.  For example, the forwarder can unload the dll itself
> directly (assuming that unloading the dll will cause the various
> atexit and global descructors to run).  If you can attach dtors to the
> thread itself, you can forward from there directly.

More information about the Gcc-bugs mailing list