[LAD] A question to plugin host devs

[Robin Gareus]

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