[PATCH RFC] fork: reduce chances for "address space is already occupied" errors

[Michael Haubenwallner]

Hi Brian, hi Achim,

Thanks a lot for your input!

On 3/30/19 5:09 PM, Brian Inglis wrote:
> On 2019-03-30 02:22, Achim Gratz wrote:
>> Brian Inglis writes:
>>> On 2019-03-29 14:23, Achim Gratz wrote:
>>>> Brian Inglis writes:
>>>>>> If you are packaging your own exes and dlls with your own local Cygwin distro,
>>>>>> you should point to your local utility directory with a path in a file under
>>>>>> /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or perhaps
>>>>>> you might also need to add your own production exes and dlls into
>>>>>> /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see
>>>>>> /usr/share/doc/Cygwin/_autorebase.README.
>>>
>>> I was wondering as my first para above stated, whether rebase_user{,_exe} would
>>> be the proper place to add 3rd party Cygwin dlls and exes, that are distributed
>>> with Cygwin (internally)?
>>
>> Well, if you are distributing something (even just locally), then
>> preferrably you make proper Cygwin packages and you will never have to
>> deal with rebase yourself.
>>
>> The options you allude to above are meant for cases where that just
>> isn't possible and so you install things without using setup and often
>> also outside the Cygwin install (permanently, not temporarily until it
>> gets packaged).  You still need to run setup after each change so
>> autorebase can pick up on it.
> 
> Thanks Achim,
> 
> I think that those are possibly the answers the OP Michael was looking for,
> depending on how they are using Gentoo Prefix: it did not seem like they were
> installing their dlls and exes using Cygwin setup, but they could still run
> autorebase under dash.

Beyond being portable across many operating systems (*nix, MacOS, Cygwin, ...),
one of the main goals for Gentoo Prefix is to provide it's packaging mechanism
without the need for any privilege elevation on the underlying operating system,
nor coping with the various underlying operating system's packaging mechanisms.

On a side note:
To get it working as intended on Cygwin, I had to extend Cygwin fork() to allow
for updating dlls and executables while the process is running, as the Gentoo
Prefix package manager is a Cygwin program by itself - unlike Cygwin setup.exe,
which is a non-Cygwin executable and requires Cygwin processes to be terminated.

Before I really can tell what I need regarding the rebase, I need to learn what
exactly is recorded into the rebase database, and probably how the recorded data
does influence the rebase procedure right now.

My thoughts so far for what I probably need:

* First, rebase new dlls before being installed into the target file system
directory with respect to currently installed dlls (the --oblivious option),
* Second, register new dlls just installed into the target file system
directory into the rebase database without performing a rebase, and
* Third, unregister dlls being removed from the rebase database.

Also, it may make sense to allow for reusing the base address of an installed
dll by it's update replacement - while the old version dll still is in use and
the new version dll is in some temporary staging directory.

As there may be multiple instances of Gentoo Prefix within one single operating
system instance, it does not make sense to record the dll's base addresses into
the rebase database of the underlying Cygwin instance in /etc, but still the
base addresses already recorded there should be respected when rebasing dlls
for within a particular Gentoo Prefix instance.

Furthermore, with so called "Stacked Prefix", it is possible to have a second
level of Gentoo Prefix, so what I'm after is some option to tell the rebase
utility which database to record dll base addresses into, and which multiple(!)
databases take into account while performing a rebase.

Thanks!
/haubi/