Use dlmopen for modules to clearly separate symbol namespace

[jaromil]

Is this the dlopen call for loaded modules?

tarantool/src/box/func.c

Line 276 in ca07088

module->handle = dlopen(load_name, RTLD_NOW | RTLD_LOCAL);

I'm wondering if you are open to a change to the way you load modules, to adopt dlmopen as I've described here redis/redis#6125

This change would allow modules to carry their own symbols without clashing with tarantool's.

For instance modules with their own modified Lua interpreter.

[cyrillos]

Actually it looks tempting to support but we need more time to figure out the details and potential side effects.

[cyrillos]

Thinking more I fear this might break backward compatibility. What if there already present users/modules which relies on global symbol namespace?

[jaromil]

Yes, glibc's dlmopen provides complete isolation; but fallback can be handled by the host application.

I see a solution here and I wish also @antirez would consider it for Redis, I'm speaking based on experience made maintaining frei0r and following LADSPA, both large third-party communities of plugin developers.

The solution can be to add metadata that indicates loading options (and more) for plugins.
Such metadata can be either an external file (LADSPA uses rdf) that goes side-by-side with the binary DSO or a function symbol of the DSO to be called after an initial dlopen and returning a struct of options.

Then the flow can be:

1. read metadata (file load, or dlopen+setup() call)
2. if setup() returns full isolation option, dlclose() and dlmopen() the DSO
3. pass the DSO pointer and process

There may be more solutions, in any case I recommend you do consider the isolation flag as a desirable option for plugin developers.

[cyrillos]

Yes, I think of some kind of flag to provide an option for such load, but definitely we won't switch to dlmopen by default.

[jaromil]

Ping. Any thoughts about this? A runtime configuration switch?

[cyrillos]

Hi! Sorry but have had no time to think about, -EBUSY :(