Re: [PATCH] Add RTLD_RELOAD to dlopen

[Samuel Thibault <samuel.thibault@ens-lyon.org>]

Carlos O'Donell, on jeu. 20 juil. 2017 16:03:46 -0400, wrote:
> On 07/20/2017 03:34 PM, Samuel Thibault wrote:
> > Carlos O'Donell, on jeu. 20 juil. 2017 15:31:38 -0400, wrote:
> >> On 07/20/2017 03:15 PM, Samuel Thibault wrote:
> >>> In our parallel programming projects, we would like to load some DSO
> >>> several times within the same process, because we want to share the
> >>> addresse space for passing data pointers between parallel executions,
> >>> and the DSO has global variables and such which we want to see
> >>> duplicated.
> >>>
> >>> Unfortunately, dlopen() does not re-load the DSO when it is already
> >>> loaded. One workaround is to cp the file under another name, but that's
> >>> ugly and does not share the memory pages.
> >>>
> >>> The patch proposed here simply adds an RTLD_RELOAD flag which disables
> >>> checking for the DSO being already loaded, thus always loading the DSO
> >>> again. There is no actual code modification, only the addition of two
> >>> if()s and reindent.
> >>  
> >> This is what Solaris designed dlmopen() for, is there any reason you
> >> can't use dlmopen()?
> > 
> > Because only that DSO should be reloaded. All the dependencies are fine
> > to use as such, to avoid memory usage duplication.
> 
> Is that really a problem? Have you measured this?

Yes and yes. We are targetting loadling like thousands of replicates of
the DSO, to emulate a very large parallel execution.

> The kernel will share every page except data/bss.

But that also eats addressing space and VMAs.

> Using dlmopen will protect you from all kinds of issues with dependent
> libraries only supporting a single global state since you'll get unique
> state for each of the loaded libraries.

Sure, but it's really too costly for us, and it loads glibc several
times in the process, which can pose other problems.

> I see RTLD_RELOAD as an shortcut to simply having multiple copies of the
> shared library on disk. I believe you could use hardlinks and glibc should
> load each as a unique library.

Hardlinks would have the same st_ino, so libc would detect it is already
loaded.

Samuel