Date: Tue, 04 Feb 2003 11:12:02 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: arch@FreeBSD.org, Alfred Perlstein <bright@mu.org>, Wes Peters <wes@softweyr.com>, Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org> Subject: Re: dlclose() vs. atexit() Message-ID: <3E401082.6C6512F8@mindspring.com> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041046.13767.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > Last time I brought this up, it was not clear, what The Right Thing to > do is. Are these details mandatated by some standard out there, or is > everyone on their own, and we should, indeed, do what Linux does, to not > increase the enthropy? > > Should, for example, exit handlers, which will still be valid after the > dlclose() still be called at dlclose() or at the actual exit()? How > about atexit() calls made between dlopen() and dlclose(), and not by the > library but by the application, or by another library? Have each library > get its own list of exit-handlers? > > Or should it still be a global list, but examined by both dlclose() > and exit() -- if an item on the list is about to become invalid after > dlclose() (how can we know, BTW?), have dlclose() call it -- otherwise, > leave it alone? FWIW, the way Windows handles this is to have various entry point to manage this: ProcessAttach Called after a process attaches to a shared object ProcessDetach Called before a process detaches a shared object ThreadAttach Called after a thread attaches to a shared object ThreadDetach Called before a thread detaches a shared object The key here is that all processes have at least one thread. These are really the entry points, not the atexit(), that should be used. Right now, FreeBSD can at least do the Process[Attach|Detach] for dlopen'ed objects, by abusing the .init and .fini sections, and/or abusing the .ctor and .dtor sections. Probably, this is the correct approach, overall, but requires some small mod to crt*.c to make it entirely happy (declaring multiple .init/.fini sections displaces, rather than aggregating them, as only the first entry in the linker set is invoked, not the whole list, and using the .ctor/.dtor approach requires using the C++ crt*.c in the C case). I've actually posted code to abuse .init/.fini to this list in the past, a part of creating a static libdlopen. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E401082.6C6512F8>