[LAD] A question to plugin host devs
robin at gareus.org
Sun Dec 20 19:41:13 CET 2020
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
> 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.
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.
More information about the Linux-audio-dev