20 Dec
2020
20 Dec
'20
8:41 p.m.
On 12/20/20 5:59 PM, Fons Adriaensen wrote:
Hello all,
I wonder what are the pros and cons of using RTLD_NODELETE as
a flag to dlopen() and call dlclose () as soon as the required
symbols are loaded.
The alternative is to leave all shared object handles open until
the host terminates.
Why keep it around?
As soon as the last plugin instance is deleted from a session the
plugin's shared object can and should be unloaded. Otherwise you would
just accumulate [shared] memory simply by adding and removing different
plugins.
What are you doing in your plugin host
VST3 and LV2 reference implementation for Linux just use RTLD_LAZY
(along with dlopen's default RTLD_LOCAL), and dlclose() when the last
instance is removed.
That is also what Ardour does for LV2 and VST3.
I do not know any plugin host that uses RTLD_NODELETE.
Besides, NODELETE is not portable. macOS' CFBundleLoadExecutable() and
Windows LoadLibraryExA do not have equivalent mechanism.
In the distant past, Ardour (really libsuil) used NODELETE for LV2 GUIs.
https://lv2plug.in/ns/extensions/ui#makeSONameResident
but that is no longer the case since the option was deprecated.
(and why)
Accumulating memory generally degrades overall performance. The larger
the page table, the more expensive are context switches.
[Re]Loading the shared object adds overhead of static initialization,
which is usually done in the GUI thread and fast compared to any user
interaction. It's also a one time operation, not a periodic one.
As a side-effect it also aids plugin-developers. If a host unloads the
.so. A dev can recompile the plugin and reload it in the same session.
Cheers!
robin