Re: static object destruction in shared library

[Mike Stump <mrs at windriver dot com>]

Please don't send HTML in email to lists, it is just plain annoying.

> From: "Jeff Greif" <jmg@trivida.com>
> To: <gcc-bugs@gcc.gnu.org>
> Date: Wed, 1 Dec 1999 18:31:42 -0800

> For example, suppose you use a static thread-related object in a
> dll.  When you shut down a process that has multiple threads by
> calling exit or returning from main(), the outstanding threads other
> than the main thread just happen to be destroyed before any dlls are
> unloaded.  Running the destructor of the dll's static object may
> then cause an illegal memory access.  It's likely that the order
> thread destruction preceding dll unload was chosen based on other
> nasty interactions (an obvious candidate being the the
> thread-related functions of the runtime library usually loaded
> dynamically).

I don't buy it.  Or put another way, I don't mind having requirements
like, thou shalt not unmap memory before running atexit functions and
burning the user if he manages to blow it.

If you have thread local data, it will be destroyed when the thread is
destroyed.  The fact you later unload an object won't matter.  If the
object isn't thread related, then it will be associated with the
object that has it's data storage.  When that storage is unloaded, it
will be destroyed then (just before the unloading).  Yes, the user can
have dangling pointers to data that has already been destroyed, and
can do bad things with them, but they should be fired.

The best I can get out of the description above is just such a
dangling pointer problem.  Can you explain why it isn't a dangling
pointer problem?  Rough pseudo code would be fine.  Your description
is pretty good, but forgive me, I just can't follow it well enough to
see _exactly_ what you mean.

The obvious solution to dangling pointers are things like proxies and
GC schemes that can cope with such nasties.

For example, you have a dynamically loaded object that contains some
data and all the methods to work on that data.  You squirrel away
reference to this via a smart reference.  The object is unloaded.  The
object goes away, but before it does, it updates all the smart
references that it is gone and sets them to `invalid'...  Future
references to the smart reference will now just throw instead of
`doing bad things'.