X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: Updated cygwin dlls cause unnecessary reboot on NT
Date: Wed, 27 Dec 2006 23:21:58 +0000 (UTC)
Lines: 132
Message-ID:  <loom.20061228T000321-458@post.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>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
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

Linda Walsh <cygwin <at> tlinx.org> writes:

> > Linda, I think we've reach this point here, unless you're willing to try
> > to understand why "fork()" is important to Cygwin.
> ---
>     I am aware of why "fork" is important.  Apparently, there is
> some impression that I am trying to change fork?  I'm not
> suggesting this. 

Actually, you are.  The ONLY way to make renaming in-use .dlls work is to make 
fork() aware of the rename.  The way fork() works is that it must reload the 
same .dll as the parent process had loaded, and it currently does this BY 
NAME.  In other words, changing the name of an in-use dll will break the child 
process, even if you then install another dll at that location, because the new 
dll will have a different layout in memory, and will not reload cleanly.  For 
your scheme to work, you must teach fork() how to track these renames, and load 
the original .dll by its new name, and not the upgraded dll that now lives at 
the original name.

>     The code for "fork" is part of the cygwin1.dll.  Changes needed to
> make setup work are only part of setup.  The way to move libraries
> into and out of use can be done at the Shell level -- no changes to
> cygwin are needed.

That statement is false.  Reread our explanations - you cannot just change 
setup.exe to get renaming to work if a dll is in use, you also have to change 
cygwin itself.

> 
>     I saw a note about deleting necessary runtime libraries from
> bash and watching it fail.  I believe this was meant to show that
> cygwin has to "pretend" to duplicate the processes address space
> by rebuilding it from its components rather than the address
> spaces actually being fully copied as on *nix.  If someone renames
> and moves a new DLL into place while bash is running, then when
> cygwin tries to duplicate the new address space, it may very
> well copy in the contents of the new DLL into the new processes
> address space rather than using the old contents.

Which WILL BREAK.  The new dll (most likely) has different memory layouts.

>  This would be
> a technical violation of the POSIX requirement that the address
> space be duplicated.  Am I misunderstanding this?

No, you are not.  It goes further than violating POSIX - it means the fork() 
will flat out fail.

> 
>     Note that the POSIX violation is only an issue when you run
> setup and have not terminated all cygwin programs.  Even then it
> is "likely" to not make a difference.

Actually, it is VERY likely to make a difference.  ALL cygwin programs 
use .dlls (some more than others, but at least cygwin1.dll), and it has already 
been pointed out to you that special casing on the dll names in use is not 
technically sound, compared to checking all dlls for whether they are in use.

>  But to prevent the possibility
> of it making a difference, cygwin chooses to require a reboot
> to replace those in-use libraries. 

Or you could use the current setup.exe snapshot (2.553), which will warn you 
that a file is in-use, and let you manually close whatever is using it again, 
all before retrying the copy, once again getting you to the situation where you 
can reliably avoid a reboot because you did the upgrade while guaranteeing that 
nothing in-use was upgraded.  In other words, we are already aware of the 
issue, and Igor already went to as much effort as he felt reasonable to at 
least warn the user that a file is in use and give them another chance, without 
forcing a reboot.

> 
>     When setup runs it still is only an issue if the user chooses to
> "not follow the instructions" and exit out of any cygwin programs
> before running setup.  Currently that may result in a requirement to
> reboot in order to continue to use the new libraries.  If the change
> was made, a reboot would not be necessary, but any programs that
> were left running (against the advice to exit before continuing in
> setup), would lose strict POSIX compliance in regards to a forked
> process being an exact copy of the previous memory space.

Any programs left running while you upgrade an in-use dll will crash the moment 
they try to fork.

>     Instead, what would happen is the new process would run with the
> new library that the user has chosen. 

Not quite.  cygwin1.dll uses a named shared memory region.  If two different 
versions of cygwin1.dll are both loaded, they interpret that region 
differently, and the second one in will fail to run.  In other words, you have 
made both the old version crash, and the new version fails to load.

>     This discussion, REALLY, isn't worth this much effort.  As
> I said before, I was addressing the misperception that DLL's couldn't
> be copied in due to a windows limitation or bug.  It was apparent
> to me that solving this issue was painfully easy for someone who
> already knew the structures, layout and location of the affected
> area(s) in setup.

You got the "painfully" part right, but the "easy" part wrong.

>  It's equally apparent that the ease of making
> this change wasn't the only issue -- such that even if I made
> the changes, there would still be technical opposition (the issue
> of POSIX correctness being at least one reason). I understand that
> such opposition is immune to logical discussion -- since,
> on technical grounds, by-the-POSIX-book, it would be incorrect. 

Here's where you are wrong.  This is an open source project.  If it is so easy, 
then please submit a patch, tested by yourself, that shows that it was easier 
than we thought - we will probably be so impressed by such a patch that we 
would install it.  What we are trying to tell you is that with our familiarity 
of how cygwin works, it will not be trivial, and none of the regular 
contributors are bothered enough by this problem to even desire to spend time 
trying to tackle it ourselves.  We are not opposed to the idea of improving the 
upgrade experience, we are just opposed to the effort that we perceive will be 
necessary to acheive such a goal when our efforts could be better spent in 
other arenas with higher benefit ratios.  Whereas if you contribute the patch, 
we have minimal effort (mainly the review time of your pre-tested patch).  And 
if it bothers you so much, even though you don't feel competent to write the 
patch yourself, then consider making a financial donation to someone who does 
feel competent.  The thought of a fair financial remuneration may make the 
difference in someone's attitude of whether writing such a patch in your behalf 
is worth pursuing.

Disclaimer - don't ask me to write the patch.  I still don't have copyright 
assignment for cygwin proper, and the only technical solution I see to 
implement your ideas involves hacking cygwin1.dll as well as setup.exe.

-- 
Eric Blake



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