9 ms·
How would that be any different, sorely a destructor function would also be unmapped with dlclose
by arka2147483647 7y ago
How would that be any different, sorely a destructor function would also be unmapped with dlclose
- rwmj 7y agoFor a start it works reliably. It's a mechanism that we use all the time on multiple ELF platforms including Linux and several BSDs. It's also the right thing to do because it is called by the dynamic loader at the correct time, ie. after the library is no longer accessible from other threads via dlsym, but before the library has been unloaded (and the code that would run is unmapped). I wouldn't even have thought to use atexit for running code on library unload.
- loeg 7y agoI believe you have the article backwards. I think the author wants atexit() from DLLs to prevent dlclose() from actually unloading the code, so that his library's atexit handler can run at exit? But libc on all these platforms actually invokes atexit handlers from shared libraries at dlclose(), or not at all. It's kind of confusing to me why the author wants this or believes it should be the default behavior.