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

[Michael Haubenwallner]

On 4/3/19 2:28 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> 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.
> 
> Just where the DLL resides in the filesystem, what address it has been
> rebased to and what size it occupies.  If you rebase a new DLL with the
> database, it will give you the first gap in the address space that this
> new DLL fits into for doing the rebase and record that into the
> database.  With the --oblivious option, it keeps the database file
> untouched, so the information about the newly rebased DLL gets lost
> whenh the program exits.  That's why you need to do all oblivious
> rebasing in a single invocation.

Ok, this does fit what I guessed, thanks!

> 
>> 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),
> 
> You always rebase after the install so that the path information is
> correct.  Pre-rebasing is useless.
> 
>> * Second, register new dlls just installed into the target file system
>> directory into the rebase database without performing a rebase, and
> 
> No, rebasing the installed DLL already does that.

Well... once installed, a dll may get in use quickly, because I can not require
to shut down all Cygwin processes.  So I need to rebase and register the dll in
some staging directory before it is installed into it's final directory, hence
 I'm about to add some new '--destdir' option.

>> * Third, unregister dlls being removed from the rebase database.
> 
> Rebase already removes any entries that are no longer accessible from
> the database.

Ah, nice.  So I don't need to care about rebased but then not installed ones.

>> 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.
> 
> Rebase already re-uses the base-address if the path for the new DLL is
> the same and it still fits into the gap.

Ok.

> In general, however, that
> won't work when the size of any DLL changes.  You can ask for more
> guardband around each entry, but that doesn't actually solve the problem
> as it's only useful for the initial (full) rebase.
> 
>> 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.
> 
> If you can limit the address space that's used by the Cygwin base
> system, I'd just give your Gentoo prefix installation its own address
> space and rebase it independently from the base system.  That probably
> requires some fooling around with the (currently hardcoded) rebase
> database files, but should otherwise just work.

When I install rebase right within Gentoo Prefix, the rebase db is stored there
as well, to not cope with host Cygwin's rebase db.  Other than cygwin1.dll, no
dll should be used by Gentoo Prefix binaries anyway (except during bootstrap).

>> 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.
> 
> I don't think you'll want to do that.

Indeed - at least not for the moment.

Thanks!
/haubi/