←back to thread

Why did dlclose not unload the library? (2023)

(kishoreganesh.com)
39 points mattrighetti | 1 comments | 27 Aug 25 00:45 UTC | HN request time: 0s | source
Show context
sgbeal ◴[30 Aug 25 13:34 UTC] No.45074556[source]▶
There is no safe, reliable, cross-environment way to deal with closing a DLL. A DLL initialization function can allocate arbitrary resources, some of which may be in use by clients of the DLL when it is closed.

The only safe, consistent, reliable approach is not to close DLLs.

replies(6): >>45074649 #>>45074720 #>>45075478 #>>45075558 #>>45075726 #>>45080214 #
10000truths ◴[30 Aug 25 13:43 UTC] No.45074649[source]▶
You can run the DLL in a "shim" subprocess that proxies function calls over IPC. Then the DLL can muck about with global state all it wants, and the OS will clean up after it when you "unload" the DLL by killing the subprocess.
replies(1): >>45074914 #
sgbeal ◴[30 Aug 25 14:21 UTC] No.45074914[source]▶
> You can run the DLL in a "shim" subprocess that proxies function calls over IPC.

That doesn't address the need of some DLLs to malloc() resources in the context of the applications linking to them.

This problem _cannot_ be solved _generically_. Any solutions are extremely API-specific and impose restrictions on their users (the linking applications) which, if violated, will lead to Undefined Behavior.

Edit: as an example of cases which must bind resources in the application's context: see the Classloading in C++ paper at <https://wanderinghorse.net/computing/papers/index.html#class...> (disclosure: i wrote that article).

replies(2): >>45075196 #>>45075239 #
1. 10000truths ◴[30 Aug 25 14:55 UTC] No.45075196[source]▶
True, it's application specific. The typical reason an application would need to load/unload DLLs cleanly and repeatedly (where the caveats of dlclose are in full force) is for a plugin system with hot-reload functionality. And for that use case, the expected API/ABI is known in advance, so the shim can be tailored for it.