Date: Tue, 4 Feb 2003 16:42:41 +0000 (GMT) From: Jan Grant <Jan.Grant@bristol.ac.uk> To: Chip Norkus <wd@arpa.com> Cc: arch@freebsd.org Subject: Re: dlclose() vs. atexit() Message-ID: <Pine.GSO.4.44.0302041640430.1699-100000@mail.ilrt.bris.ac.uk> In-Reply-To: <20030204162513.GB22642@arpa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Feb 2003, Chip Norkus wrote: > On Tue Feb 04, 2003; 10:46AM -0500 Mikhail Teterin propagated the following: > > [snip] > > > > Yet another plan would be to have the atexit() call simply increase the > > ref-count of the library a handler is from, so it will not actually be > > unloaded by dlclose(). But that will be yet another implementation... > > > > I'm not sure this would be a good idea. I have a program which > uses dynamic libraries to introduce code, and which can unload or > reload them at any time and keep on running. I am especially worried > about the reload case, because what often happens is that an old > version of the .so is unloaded (dlclosed) and then a new version > is loaded (dlopened). If the old version stays around, I'm afraid > there would be some symbol collision. Correct me if I'm wrong, > though. > > I think the Solaris approach you mentioned above is by far the best > and most correct sounding approach. I agree; I've done similar work with dlopened libraries which were "updated" over time, dynamically. The atexit() / dlclose() behaviour seems robust and "does the right thing". If you want more complex behaviour (eg, persisting library state while you update a dynamic library) then you have to roll your own. That's not a big deal. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ There's no convincing English-language argument that this sentence is true. 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?Pine.GSO.4.44.0302041640430.1699-100000>