This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add RTLD_RELOAD to dlopen
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