X-Spam-Check-By: sourceware.org
Date: Thu, 28 Dec 2006 00:35:08 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Updated cygwin dlls cause unnecessary reboot on NT
Message-ID: <20061228053508.GA10087@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <45910426 DOT 9030603 AT tlinx DOT org> <459133CB DOT 3080102 AT ukf DOT net> <45916391 DOT 1090906 AT tlinx DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0612261313480 DOT 27982 AT access1 DOT cims DOT nyu DOT edu> <45919F7B DOT 8000702 AT tlinx DOT org> <4591FA3C DOT 3020402 AT cygwin DOT com> <4592FB08 DOT 2020205 AT tlinx DOT org> <loom DOT 20061228T000321-458 AT post DOT gmane DOT org> <emv9f1$9fl$1 AT sea DOT gmane DOT org> <459353AD DOT 20101 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <459353AD.20101@byu.net>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Wed, Dec 27, 2006 at 10:18:37PM -0700, Eric Blake wrote:
>> Another question, how is this not a problem for Unix's fork()? Does
>> Unix's fork also do this by name? Or does it use another mechanism?
>
>Unix's fork is provided natively by the kernel, using copy-on-write
>semantics.  It is an entirely different beast than faking fork on Windows
>(for starters, it is orders of magnitude faster).  Unix could care less
>what shared library filenames were previously opened - the ENTIRE address
>space is already faithfully copied to the child process, without having to
>reload libraries by name.  But Windows is woefully lacking in this area,
>so cygwin fakes this by starting the child process, using a shared memory
>region to inform the child exactly what the state of memory in the parent
>was, then the child must manually reload the same dlls the parent had
>open, at the same address.  Painfully slow already, and not worth making
>slower just to track dll renaming.

I have considered, however, modifying fork so that it just starts a
small "cygfork.exe" and copies all of the real memory that it needs
straight from the parent process - including text segments and data
segments from dlls/exes.

That's a lot of work and I'm not sure that it would be any faster since
you don't get to use the direct OS paging from .exes and .dlls anymore.
And, you'll see a bunch of "cygfork.exe"s running rather than, e.g.,
bash.exe.

(and, of course, I, and others have experimented with copy-on-write
techniques and found that Windows doesn't quite provide what you need)

>> (I'm not saying that Cygwin's fork == Unix's fork - indeed perhaps there
>> are deep technical reasons why using a file descriptor approach is
>> infeasible in Cygwin under Windows).
>
>Indeed, read the docs in CVS to gain an appreciation for the deep
>technical magic going on during cygwin's fork():
>http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5&content-type=text/x-cvsweb-markup&cvsroot=src

Some of the discussion in the link above is dated.  I'll have to update
that someday.

The way that fork works has not changed too much from Steve
Chamberlain's original implementation in 1996 or so.  I've tweaked the
living daylights out of it but I don't think I've ever managed to
improve very much on the original way of doing things.

cgf

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