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 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev