4 ms·

I don't see how the behaviour he wants can work. If you dlclose a library and cause it to be unmapped then the function pointers in that library are invalid and

I don't see how the behaviour he wants can work. If you dlclose a library and cause it to be unmapped then the function pointers in that library are invalid and can't be called atexit. Either, dlclose will have broken behaviour by keeping libraries mapped even though all their dlopen references have been dropped or atexit will be broken.

rwmj 7y ago
Right, he should be using a destructor instead, although AFAIK that requires (in C) both ELF and a non-standard compiler extension albeit those are available everywhere it matters on Linux and *BSD.
- arka2147483647 7y ago
  How would that be any different, sorely a destructor function would also be unmapped with dlclose
  - rwmj 7y ago
    For 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 ago
      I 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.
kazinator 7y ago
POSIX doesn't require that dlclose must unmap a library forcefully. Basically it can be that if atexit has been called with an address pointing into a shared library, that's considered a reference to the library which prevents it from being unmapped. How can it be unmapped? It's registered to be called when the process terminates.
- deleted 7y ago
  [deleted]

rwmj 7y ago

Right, he should be using a destructor instead, although AFAIK that requires (in C) both ELF and a non-standard compiler extension albeit those are available everywhere it matters on Linux and *BSD.

arka2147483647 7y ago
How would that be any different, sorely a destructor function would also be unmapped with dlclose
- rwmj 7y ago
  For 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 ago
    I 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.

kazinator 7y ago

POSIX doesn't require that dlclose must unmap a library forcefully. Basically it can be that if atexit has been called with an address pointing into a shared library, that's considered a reference to the library which prevents it from being unmapped. How can it be unmapped? It's registered to be called when the process terminates.

deleted 7y ago
[deleted]