X-Spam-Check-By: sourceware.org
Message-ID: <45916391.1090906@tlinx.org>
Date: Tue, 26 Dec 2006 10:01:53 -0800
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Updated cygwin dlls cause unnecessary reboot on NT
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>
In-Reply-To: <459133CB.3080102@ukf.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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

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.

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

    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.

    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. 
You can have semantic excuses why not to do it, or you can do it
and have a friendly user experience, in general.  If the user is
truly concerned about correctness, let them assure that no Cygwin
processes are running when performing an upgrade.  At least that
is then under the control of the user.

    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.

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

> Could this be worked around? Perhaps.
> Is it likely to happen? No, the benefit-to-work ratio is too low.
>   
Is this a problem that needs to be worked around?  No, the
cost-benefit ratio is too high.
 
-l




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