4 ms·

Side note: dynamic library unloading (and, for that manner, multiple loading of the same library; see `dlmopen`) is finicky because the language has no concept

by o11c 3y ago

Side note: dynamic library unloading (and, for that manner, multiple loading of the same library; see `dlmopen`) is finicky because the language has no concept of ownership of things like function pointers and pointers to static data. It's easy to imagine a better language, though this would of course require a lot of low-level implementation work!

dataflow 3y ago
> the language has no concept of ownership of things like function pointers and pointers to static data. It's easy to imagine a better language I actually have both a hard time imagining a better language (not saying it's impossible, just that it's not trivial for me to see) and also how ownership would resolve this issue. Could you elaborate?
lldb 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
      It's not much different. But programmers tend to assume that static data lives forever and don't always think of this problem.
pjmlp 3y ago
Which is why that kind of stuff only works properly with languages that combine dynamic loading with rich runtimes, alongside automatic memory management, having all puzzle pieces to work together to keep the application running when the library is removed again. I came to accept that in languages like C and C++, the best path for dynamic loading code is really via OS IPC and external processes, the decrease in hardware resources and simpler programming model of using shared libraries as plugins, isn't worth the endless amount of debugging hours regarding program crashes.

by o11c 3y ago

dataflow 3y ago

> the language has no concept of ownership of things like function pointers and pointers to static data. It's easy to imagine a better language I actually have both a hard time imagining a better language (not saying it's impossible, just that it's not trivial for me to see) and also how ownership would resolve this issue. Could you elaborate?

lldb 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
    It's not much different. But programmers tend to assume that static data lives forever and don't always think of this problem.

pjmlp 3y ago

Which is why that kind of stuff only works properly with languages that combine dynamic loading with rich runtimes, alongside automatic memory management, having all puzzle pieces to work together to keep the application running when the library is removed again. I came to accept that in languages like C and C++, the best path for dynamic loading code is really via OS IPC and external processes, the decrease in hardware resources and simpler programming model of using shared libraries as plugins, isn't worth the endless amount of debugging hours regarding program crashes.