X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Andrew DeFaria <Andrew AT DeFaria DOT com>
Subject:  Re: Updated cygwin dlls cause unnecessary reboot on NT
Date:  Wed, 27 Dec 2006 23:45:53 -0600
Lines: 48
Message-ID: <emvlmj$uac$1@sea.gmane.org>
References:  <458EE598 DOT 3010404 AT aim DOT com> <458F31B1 DOT 6050804 AT byu DOT net>  <458F81CC DOT 3090500 AT tlinx DOT org> <458FDC4E DOT 9040505 AT cygwin DOT com> <458FEC2E DOT 70705 AT tlinx DOT org>  <Pine DOT GSO DOT 4 DOT 63 DOT 0612251346240 DOT 27982 AT access1 DOT cims DOT nyu DOT edu> <45902BC4 DOT 50803 AT tlinx DOT org>  <4590BD4E DOT 5020905 AT cygwin DOT com> <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=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <459353AD.20101@byu.net>
X-IsSubscribed: yes
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

Eric Blake wrote:
>> This part peaks my curiosity. Now I'm not a kernel guy however as you 
>> state fork currently knows which dlls to load for the child by name. 
>> While that makes sense on the outside what if it knew which dlls to 
>> load by number - by open file descriptor number that is?
> If only Windows had a reliable mechanism that tied open file 
> descriptor number back to the current filename, even after the file is 
> renamed using Windows APIs. But it doesn't, so cygwin has to manually 
> track the filename to file handle mapping by itself. And so renaming a 
> file breaks cygwin's tracking of that filename.
I obviously don't understand the internals fully however I don't see why 
one needs to still think in terms of filenames. If you're fork and you 
have a file description, can't you simply read the file from beginning 
to end thus making an in memory copy without having to or needing to 
know what the filename is for that file descriptor?
>> I mean wouldn't that be a clean way to change fork() to allow it to 
>> load the proper, in this case, old dlls?
>>
>> 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.
Hmmm... I see. This almost makes sense to me - but just barely. Thanks 
for the enlightenment.
>> (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
That may be a little more information than I'm willing to delve into at 
this time... OK, I read it. Tis indeed more complex than I initially 
thought...

-- 

Andrew DeFaria <http://defaria.com>
Everything should be made as simple as possible, but no simpler.


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