X-Spam-Check-By: sourceware.org
Message-ID: <45ACCBEF.49170261@dessent.net>
Date: Tue, 16 Jan 2007 04:58:23 -0800
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin Python/PIL TCL/TK fork rebase solution
References: <87ejpvluvj DOT fsf AT superfluity DOT lefae DOT org> <3D1F5241A4BA56B7EBA1D30B AT qjunbur DOT quns DOT cam DOT ac DOT uk> <45ACC59F DOT 397A6589 AT dessent DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/