16 ms·

I tested this recently and it definitely works as expected in c++ - destructors of static lifetime variables are called when the library is unloaded.

by lldb 2y ago

rwmj 2y ago
Only in trivial cases. The problem is when another part of the program holds a function pointer into the library which has been unloaded. This can happen in particular when you combine libraries and threads: libvirt has long been linked with -Wl,-z -Wl,nodelete to avoid this: https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89fbc0b54fde15f130707a0d81e https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f... Another case in libnbd which really demonstrates how hard this is: https://gitlab.com/nbdkit/libnbd/-/commit/368e3d0d5a8871aad5e1d3e9b96dc52f03cdfc7b https://gitlab.com/nbdkit/libnbd/-/commit/368e3d0d5a8871aad5...
- alexey-salmin 2y ago
  > The problem is when another part of the program holds a function pointer into the library which has been unloaded. How is this different from holding a pointer to an object being deleted?
  - rwmj 2y ago
    That it's very hard to avoid (we think in fact impossible), because of the way that Linux _exit(2) works when you have threads, destructors and thread-local storage together. This is even if you are very careful. You should probably read the links I posted.
    - alexey-salmin 2y ago
      I did and this looks like a library design issue, which is now impossible to solve without breaking the ABI. I argue though that a design that doesn't suffer from this issue exists because there is a way to serialize all these operations in a safe way.
      - rwmj 2y ago
        Thread-local storage + destructors is, as far as we can tell, impossible to use safely by any significantly complicated program or library. It's largely because of how Linux shoots down programs on exit by killing the threads in any order without notice. It could be fixed in Linux, although I can also understand why Linux developers wouldn't want to do that as it would push significant complexity there.
  - jenadine 2y ago
    It's not much different. But programmers tend to assume that static data lives forever and don't always think of this problem.

I tested this recently and it definitely works as expected in c++ - destructors of static lifetime variables are called when the library is unloaded.

by lldb 2y ago

I tested this recently and it definitely works as expected in c++ - destructors of static lifetime variables are called when the library is unloaded.

rwmj 2y ago

Only in trivial cases. The problem is when another part of the program holds a function pointer into the library which has been unloaded. This can happen in particular when you combine libraries and threads: libvirt has long been linked with -Wl,-z -Wl,nodelete to avoid this: https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89fbc0b54fde15f130707a0d81e https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f... Another case in libnbd which really demonstrates how hard this is: https://gitlab.com/nbdkit/libnbd/-/commit/368e3d0d5a8871aad5e1d3e9b96dc52f03cdfc7b https://gitlab.com/nbdkit/libnbd/-/commit/368e3d0d5a8871aad5...

alexey-salmin 2y ago
> The problem is when another part of the program holds a function pointer into the library which has been unloaded. How is this different from holding a pointer to an object being deleted?
- rwmj 2y ago
  That it's very hard to avoid (we think in fact impossible), because of the way that Linux _exit(2) works when you have threads, destructors and thread-local storage together. This is even if you are very careful. You should probably read the links I posted.
  - alexey-salmin 2y ago
    I did and this looks like a library design issue, which is now impossible to solve without breaking the ABI. I argue though that a design that doesn't suffer from this issue exists because there is a way to serialize all these operations in a safe way.
    - rwmj 2y ago
      Thread-local storage + destructors is, as far as we can tell, impossible to use safely by any significantly complicated program or library. It's largely because of how Linux shoots down programs on exit by killing the threads in any order without notice. It could be fixed in Linux, although I can also understand why Linux developers wouldn't want to do that as it would push significant complexity there.
- jenadine 2y ago
  It's not much different. But programmers tend to assume that static data lives forever and don't always think of this problem.