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

[Achim Gratz]

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.

> 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.

> * Third, unregister dlls being removed from the rebase database.

Rebase already removes any entries that are no longer accessible from
the 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.

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

> 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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables