RTLD_LAZY vs RTLD_NOW in PluginLoader
osrf-migration opened this issue · 2 comments
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Migrated from https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/issues/34/rtld_lazy-vs-rtld_now-in-pluginloader (gazebosim/gz-common#34)
Looking at the PluginLoader
implementation, we're using the RTLD_LAZY
as the flag parameter when calling dlopen
. Here's a description of the available flags.
Based on the documentation and a chat with @mxgrey, we conclude that Ignition Common doesn't have a particular preference between RTLD_LAZY
or RTLD_NOW
. The main implications seem to affect performance. RTLD_NOW
front-loads some of the work when dlopen()
is called at the cost of resolving symbols that might not be used. On the other hand, RTLD_LAZY
returns faster from dlopen()
but it will require to resolve the symbol the first time is really used.
To accommodate the different use cases from the Ignition Common users, we could expose the ability to choose the mode to the users. We discussed two options:
- Expose the flag at the
PluginLoader
class. All subsequent calls toLoadLibrary()
will use the previously set flag. - Expose the flag as a new
LoadLibrary()
parameter (possibly with a default option).
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
comment by @clalancette migrated from https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-common/issues/34/rtld_lazy-vs-rtld_now-in-pluginloader (gazebosim/gz-common#34)#comment-44753481
My main concern with RTLD_LAZY
vs. RTLD_NOW
isn't really with performance, but more with debugging. As I see it, the big problem with RTLD_LAZY
is that you don't find out if you can't resolve a symbol until you actually try to call that symbol. That means that the program may be successfully running for a while, and then when some new functionality gets invoked the program crashes because it can't resolve the symbol. If we did RTLD_NOW
, then the symbol resolution would fail at program startup time and it is an easy thing for a developer to see, understand, debug, and fix.
With that said, I'd be in favor of just switching ignition to RTLD_NOW
and leaving it at that. If we want to make it configurable, I'm fine with that too, but would prefer RTLD_NOW
to be the default.
Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).
Failing early by default makes sense.
I would recommend a flag for the LoadLib(~)
function, since I think whoever is loading the library would have the best sense of how it should be loaded. But being able to set the Loader's default in addition to that would be reasonable.