This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updated cygwin dlls cause unnecessary reboot on NT


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@cs.nyu.edu | igor@watson.ibm.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]