Re: __attribute__ ((destructor)) functions vs static global variables
Re: __attribute__ ((destructor)) functions vs static global variables
- Subject: Re: __attribute__ ((destructor)) functions vs static global variables
- From: Andreas Grosam <email@hidden>
- Date: Sat, 6 Aug 2005 15:31:59 +0200
On 04.08.2005, at 23:48, Markus Hitter wrote:
Jesper,
thought I'd share some of my limited knowledge ...
Am 04.08.2005 um 18:59 schrieb Jesper Papmehl:
My guess is that the runtime code is destructing static data before
calling the "bundle destructor".
Apps on Mac OS X don't care about destructing data, AFAIK. They simply
quit and mark the memory as free. At least, the -dealloc method of
Cocoa objects isn't sent if the object has a lifetime until the app's
end.
IF Jesper meant the d-tors of static C++ *objects* -- of course, they
will be called (implicitly).
Otherwise, explicitly defined termination functions will be called
*before* the mach-o image will be unloaded. (of course).
But IF the question was whether compiler generated d-tor functions of
static C++ objects will be called *before* the explicitly marked
"terminator" functions in the same linkage - then - frankly, i dunno.
But just try it - via printf or something.
Note also, that the behavior - namely the *order* of calling the
d-tors of static objects - is also different in GCC4 and prior
versions! There was a bug in pre GCC4 - and actually I also had
problems with Mach-O and CW.
Is there any way to control this behavior?
Do your work from some higher level, e.g. the Quit menu handler. An
alternative might be atexit(3).
atexit() only registers functions called at exit, which is called when
main() returns. exit() also terminates the process.
The reason I need this: In our class library, we have a mechanism to
register functions that should be called when the current code module
"exits". For an app, that is when the app quits. For a loadable
bundle (and frameworks), that is when the bundle is unloaded.
It's news to me dylibs (frameworks, plugins) can be unloaded at all
without quitting the app.
You can unload loadable shared libraries (e.g. a MacOSX loadable
bundle), if there are no other references anymore. see dlopen (3),
dlclose (3).
The Objective-C runtime, however, keeps references to all loaded shared
libs, thus you can't *never* unload a loaded shared lib :-(
(switch to C++ ;-) )
But, to Jesper's question:
I would use a static C++ object which c-tor/d-tor actually performs
your "start" and "termination" behavior.
In GCC4, it is guaranteed, that construction is in order, and also that
termination is in reverse order.
So, you need just to ensure that you construct this object first - for
instance, it is the only static one, and contains other objects.
Note, in gcc-3.3, termination is in the same order as construction of
the static C++ objects!! you might get trouble if you rely on reverse
order of destruction!
(When building with CodeWarrior, this isn't a problem, mainly because
you have to destroy statics yourself by calling
__destroy_global_chain(), and then you have control over exactly when
it is done.)
Yeah, CodeWarriors have no fear to dive deep into runtime stuff :-)
Yeah, but you also have to press and turn that knobs and buttons.
Andreas
If you have some code which attempts to unload your module, you have a
hook to unregister your functions as well, don't you?
Again, that's only my $0.02. Hope it's helpful anyways.
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden