On Mon, 31 Dec 2007 19:01:23 -0800 Tim Kientzle <[EMAIL PROTECTED]> wrote:
> Markus Hoenicka wrote: > > Alexander Kabaev writes: > > > As designed. atexit should not be used by shared objects that do > > > not expect themselves to live until actual exit() happens. ELF > > > provides proper _init/_fini sections to support shared object > > > initialization/destruction. > > > > > > > That is, the only real solution to this problem is to convince the > > Firebird folks to remove their atexit() calls from the client > > libraries? > > I suspect they never considered that their dynamic library > might be used via dlopen()/dlclose(). The real question is > whether they're interesting in supporting this model. > If the Firebird folks aren't interested in having their > library be accessible in that fashion, then you have > little choice but to simply forgo unloading this particular > library. > > It's a bit unfortunate that there is no standard way > to remove an atexit() registration. It would probably > be easier to convince the Firebird folks to remove the > registration as part of their cleanup routines (and > you could then invoke those cleanup routines manually > for that case). > > > Also, I'm wondering how other OSes handle this. I don't see this > > code crash on Linux, contrary to its design as you say. > > I would be curious to see the results of running your > sample program (with lots of extra fprint(stderr...) > calls, of course) on Linux to see whether it calls the > registered exit function at dlclose time or never. > Linux pulls hidden atexit symbol into every binary that uses it by means of linking in libc_nonshared.a into every glibc consumer. Having local function allows for reliable determination of who has called the atexit function. Linux calls atexit entries at object unload time. Solaris implements a libc callback from ld.so.1 to cleanup dangling pointers from objects being unloaded. This resets sigaction entries, atfork and atexit callbacks. Solaris calls atexit callback when removing it too. I guess we better follow the suit, if anyone wants to that. I prefer Solaris approach myself, but see the reason for Linux one too. -- Alexander Kabaev
signature.asc
Description: PGP signature
