X-Spam-Check-By: sourceware.org
Message-ID: <45AD15BD.5ED52565@dessent.net>
Date: Tue, 16 Jan 2007 10:13:17 -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> <45ACCBEF DOT 49170261 AT dessent DOT net> <C997D9C1A0EA00B6C5A47F1F AT qjunbur DOT quns DOT cam DOT ac DOT uk>
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

Robin Walker wrote:

> Thanks for the explanations.  So, if I've understood things correctly, the
> difficulty boils down to cloning a parent process's address space layout
> within that of a child, which includes ensuring that DLLs appear at the
> same base within both processes.

Note that the "cloning" that is happening in the case of Cygwin is done
entirely in userspace without any co-operation from the OS/kernel,
essentially by faking it -- spawn another copy of the binary and hope
that it takes the same layout.  Note that Cygwin can do some fixups on
things like file handles and things that were allocated under its
control, but it's totally at the mercy of the operating system for
things out of its control like where DLLs get loaded.

> For this to be the problem it appears to be, I'm guessing that there must
> be some shortcoming in the Windows APIs in this area when compared with
> facilities available within other Posix-compliant OSs.

It's not so much a shortcoming, it's just a fundamental difference in
how the two operating systems were designed.  The core of process
management on Win32 is CreateProcess(), which spawns a new process from
scratch, whereas the core of process management on posix systems is
fork(), which makes a duplicate copy of an existing process.

> How does Linux deal with the same issues of having libraries (or whatever
> are logically equivalent to DLLs) potentially linked at different bases in
> the two address spaces?

The "issue" does not even exist on posix systems, as fork() is simply a
kernel syscall.  You ask the kernel to make a copy of the process and it
does.  By definition the child has the exact same memory layout as the
parent, because the kernel memory manager arranges it so.

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/