This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: p2736.C Is dtor order guaranteed?


On Thu, Jul 23, 1998 at 10:07:50AM +0200, Martin von Loewis wrote:
> Since this dlopen thing seems to be a real concern, I think Jason's
> proposal of replacing atexit is the most reasonable. What if the C++
> runtime supported unregistering registered atexit functions. E.g.
> 
> void __cp_atexit(void (*)(), void *token);
> void __cp_doatexit(void *token);
> 
> extern "C" void atexit(void (*func)())
> {
>   __cp_atexit(func, 0);
> }

If this is the approach taken, how about each cleanup function having a
statically allocated `struct link { void (*fp)(); void * data; struct
link * next; }' which is passed as the token.

This would avoid heap allocation, so you'd never run out of slots or
memory, and this would be much more helpful in an embedded environment.

I put a "data" field in the structure so as to allow the standard
destructors to be called for individual objects (no extra code?), but
that's really a separate feature.

> When constructing a static object, g++ emits a call to __cp_atexit,
> passing an per-object-file address to __cp_atexit. It also puts a DTOR
> in the object file calling __cp_doatexit with the same token.  So, if
> the object file is dlclosed before the program terminates, the C++
> runtime calls those atexit functions early. If the shared library is
> unloaded regularly, all atexit function are already called, and
> __cp_doatexit does nothing.
>
> Regular atexit calls cannot be unregistered via this mechanism, as
> they don't have a token. Still, they do interleave with the global
> destructors as required.
> 
> Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]