X-Spam-Check-By: sourceware.org
Date: Tue, 26 Dec 2006 13:46:26 -0500 (EST)
From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Linda Walsh <cygwin AT tlinx DOT org>
cc: cygwin AT cygwin DOT com
Subject: Re: Updated cygwin dlls cause unnecessary reboot on NT
In-Reply-To: <45916391.1090906@tlinx.org>
Message-ID: <Pine.GSO.4.63.0612261313480.27982@access1.cims.nyu.edu>
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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 Tue, 26 Dec 2006, Linda Walsh wrote:

> Max Bowsher wrote:
> > I believe there is a critical element you have missed.
> > In order to perform the rather miraculous emulation of fork(), Cygwin
> > needs to reload all the same DLLs that are operating in one process into
> > another newly created process. Updating the DLL files on disk whilst
> > processes are using them prevents this from happening.
> >   For a simple demonstration of this:
> >
> > * Start a bash shell
> > * Rename any of the DLLs used by bash to something else
> > * Try to execute any non-builtin command
> > * See the fork failure message
> >
> ----
>    So you are saying Cygwin doesn't properly emulate the POSIX
> fork semantics. I don't know that this is "critically" important
> for consideration in this issue.

It is.  This is the principle of least surprise for the end user.  Right
now the behavior is simple: if you had in-use files while updating Cygwin,
you will have to reboot.  If we go into the "depending on what parts you
have upgraded and what processes you had running at the time, you may or
may not have to reboot, and your shell may or may not work correctly after
the update" mode, imagine the number (and quality) of error reports we'll
get on this list.  Especially since, in that case, setup won't be able to
tell the user that she needs to reboot (or will have to conservatively do
this every time, which is no different than the current behavior).

> If you need such critical precision, it sounds like you should be
> using a full POSIX environment.

The point is that this precision is expected not by the end users, but by
applications.  So, any application compiled under Cygwin will have to have
Cygwin-specific code to deal with fork failures of this sort, which kind
of defeats the purpose of Cygwin.

>    If Cygwin's inability to emulate the full POSIX fork semantics is at
> issue, then it seems that the argument of "we can't do it because it may
> not be exactly POSIX correct" is weakened already. Cygwin could continue
> to display messages to "exit all applications" whenever you run "Setup",
> just like every installer still tells you to shut down all other
> programs on a machine before continuing an install.

And the new snapshot of setup already does that (and, in fact, gives you
the opportunity to exit those applications and continue).

>    We aren't talking about something that happens every clock cycle or
> even every day.  We are talking about taking the most user-friendly
> action when the user tries to update an inuse DLL.

The most user-friendly action is guaranteeing that the environment will be
in a working state after the update.  The only thing that accomplishes
that with the current implementation is a reboot.  It's likely that no
other behavior is possible without massive changes to the implementation
of basic Cygwin functionality (i.e., fork).

>    One of the reasons why Open-Source software isn't as user
> friendly as OS X or the Windows desktop is prizing anal-correctness
> over function.  It may fail consistently if you leave it as is and
> never allow updating without/reboot (if an inuse DLL is detected),
> or you can have something that works for most of the people, most
> of the time, even though it isn't perfect.  Unfortunately, some
> designers don't choose user-friendly, default, behaviors.

What you seem to be missing is the fact that it will *not* work for most
people.  It may not even work for you.  See below.

>    Some people asked me for a "patch".  I find that laughable -- I'm
> sure it would go the way of the UTF-8 patch that was proposed with code
> several months back.  The patch would quietly (or noisily) be killed on
> the cygwin-patches list by any of several excuses seen here.

Patches are *never* rejected without a thorough review.  Patches may be
rejected for lack of testing, or for messy integration with the existing
code.  That's actually the reason we ask *you* for a patch -- since you've
proposed this approach, it falls upon you to test it, first in your
environment, and then by making a build available for others (as I did
with a few of my setup patches before they were accepted).  Open-source
works by scratching your itch, not by getting someone else to scratch it
for you.

> But the point mentioned by Igor earlier, -- the code to rename old,
> inuse dll's and install new ones isn't difficult if one knows that it
> can be done and doesn't have a defeatist attitude about implementing it.
> Then it's most easily done by someone who knows the existing code, since
> simply finding the place to put the "patch" and creating a test DLL
> would be 3-5 times the work as creating the patch itself.

This is a standard excuse by people who don't want to do the work.  Look
at this as an opportunity to learn more about setup's codebase.  If you
want pointers on where to start looking, most of the relevant code is in
the Installer::installOne() function in install.cc.  If nothing else,
you'll have a custom version of setup that behaves the way *you* want.

However, as both Max and CGF said, it's not enough to just rename the
current DLL and replace it with a new one.  Making that work implies
changing to the fork() implementation.  If Cygwin's implementation of
fork() can handle renamed DLLs correctly, then I think the patch to setup
will be accepted without fuss.  Otherwise, I suspect it has little chance
of getting in...
HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

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