This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin Python/PIL TCL/TK fork rebase solution
Brian Dessent wrote:
> Because in order to emulate fork(), Cygwin has to be able to re-execute
> the binary and have it load with the same memory layout. If there are
> DLLs that overlap and need remapping by the OS then the memory layout
> becomes non-deterministic. If Cygwin cannot create a child process with
> the same memory layout as the parent, then it cannot fork and you get
> the "unable to remap" error.
Also note that this explains why binaries that dynamically load modules
at runtime with dlopen() (such as Perl, Python, Apache, ...) are
particular likely to be affected by this whereas if you are just running
ordinary binaries that do no dynamic loading you almost never have to
mess with rebasing. Specifically, if a process loads modules at runtime
and those modules need to be relocated by the OS then the memory layout
depends now on countless details of the execution of the script or the
logic flow of the binary. Or put differently, the Windows process image
loader (i.e. the thing that loads a .exe and all DLLs that it was linked
against at link time) is relatively deterministic and repeatable, so you
can get away with unbased DLLs if there is no runtime loading since the
memory layout is still somewhat repeatably reproducable.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html