20 Dec
2020
20 Dec
'20
6:59 p.m.
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.
What are you doing in your plugin host (and why) ?
TIA,
--
FA
20 Dec
20 Dec
7:19 p.m.
Am 20.12.20 um 17:59 schrieb Fons Adriaensen:
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.
What are you doing in your plugin host (and why) ?
TIA,
In guitarix we use RTLD_LOCAL|RTLD_NOW and we only call dlclose () when
the plug isn't compatible with our host, or when the host shut down.
RTLD_NODELETE may have a benefit when you load/unload/load/unload/ . .
. a plugin library,
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
9:03 p.m.
Am 20.12.20 um 19:41 schrieb Robin Gareus:
Why keep it around?
Guitarix is a host aimed to live performance. For performance reasons we
wont load a plugin on preset switch. So, all plugs which may be used
during a session been loaded already and been keep in memory. Other
plugs, which are not announced cant be used without explicitly load them
into the rack.
Still, we don't use RTLD_NODELETE (and can't see a benefit on using it)
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.
Wasn't that more related to the underlying libs used by plugin GUI's
from the time were using shared toolkit lib's was supported (and
pronounced) by the LV2 specs? So that the host don't unload for example
the gtk lib's when a plugin which use it was unloaded, but a other one,
which may use it as well, still is loaded?
23 Dec
23 Dec
2:50 a.m.
On 12/20/20 11:59 AM, 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.
What are you doing in your plugin host (and why) ?
TIA,
A quick search of MusE code finds no usage of it out of
21 matches on "RTLD_".
Only RTLD_NOW and/or RTLD_DEFAULT.
Tim.
1459
days inactive
1462
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
4 participants
participants (4)
-
Fons Adriaensen -
Hermann Meyer -
Robin Gareus -
Tim E. Real