RTLD_LAZY vs RTLD_NOW in PluginLoader

[osrf-migration]

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 to LoadLibrary() will use the previously set flag.
• Expose the flag as a new LoadLibrary() parameter (possibly with a default option).

[osrf-migration]

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.

[osrf-migration]

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.