This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add RTLD_RELOAD to dlopen


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?

The kernel will share every page except data/bss.

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.

I'm deeply worried about users trying to use this generically for any
DSO, and finding that initializing a DSO twice results in, for example,
overwriting global state in a dependent child library, which means the
dependent child should also have been loaded in parallel.

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. So all you need is a parallel_dlopen()
function that does the hardlink and then issues the dlopen.

We would be well served by documenting the rules under which glibc will
reload or not reload similar files on disk e.g. SONAME? hardlink? symlink?

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]