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

[Brian Inglis]

On 2019-03-29 01:15, Achim Gratz wrote:
> Brian Inglis writes:
>> File list my-dlls.txt is your local test rebase db listing all your
>> test dlls.
> 
> I think Michael got confused by your usage of "db" here.  This is in
> fact just a listing of all the DLL to operate on, not the rebase
> database (which won't be changed at all by an oblivious rebase, only
> read in order to not collide the new rebase with the already existing
> ones).
> 
>> 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.
> 
> What Michael is using is a fairly complex build system that would indeed
> benefit from a layered rebase database, i.e. the one for the base system
> providing the substrate for the build system and then at leat on other
> one that collects the information from inside the build system (maybe
> even a third layer for tests).  How to deal with the complexities of
> when you want to push information down to a previous layer would likely
> be a main point of contention, so you'd probably best skip it in the
> beginning.
> 
> SHTDI, PTC, etc.pp.
> 
> With the current rebase, you'll have to use "--oblivious" (which, again,
> doesn't remember any data for the newly rebased objects) and those
> non-existing upper layers will have to be provided by side-channel
> information that the build system has to collect and maintain itself,
> then feed to the rebase command.

Achim, thanks for the clarifications; could you please comment on the suggested
approach for handling local production dlls and exes, or explain the best
approach for migrating from test to prod and handling rebase on target systems?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.