Updated cygwin dlls cause unnecessary reboot on NT

[Linda Walsh]

Igor Peshansky wrote:
>>    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. 
---
	Least surprise for "which" end user?  Different end users
will have different expectations.  The expectations of true "end-users"
(not developers) can also be different.  Which end user are you talking
about: 1) the cygwin developer developing more cygwin apps, 2) the *nix
developer porting *nix aps, 3) the *nix developer using cygwin apps,
4) non-developer, computer literate, 5) non-devel, not especially
computer literate...or which [other]?

	I find that group "5" (the largest group, numerically, whether
or not they actually use cygwin) often is characterized as having
"unrealistic" or "uninformed" expectations.  On one hand I understand
what is meant, yet on the other hand, those are exactly the expectations
that need the most addressing (because they are expectations of the
largest group (non-cygwin experts, non-computer experts, not developers).

	Perhaps "one" eliminates group 5 on the grounds that no #5 member
would be using a "*nix"ish shell interface, let alone using a cygwin
compat layer over Windows.   However, if I'm trying to sell someone
on the usefulness of the windows command line (almost always in the
context of it being used with Cygwin), I may be aiming at someone in
group 5.


> Right now the behavior is simple: if you had in-use files while updating Cygwin,
> you will have to reboot. 
----
	The behavior may be simple -- it's the same that was predominantly used
in all Win9x OS's.  However, MS introduced WinXP in 2001 with marketing that
most software could, "now[2001]" be installed without a reboot.  It's one
of the first things I noticed about WinXP -- I rarely am required to reboot
after an application install.  Cygwin doesn't conform to this expectation.
In my opinion, this is a violation of "least surprise".  YDMV (Your Definitions
May Vary).

> 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.
---
	Yeah -- we'll see people wondering why they have ".new" files laying
around after an install. :-}.  Whether or not one has to reboot is something
that people are *used* to being told is a _possibility_ after a
reboot -- but usually, a reboot isn't needed.  IME, <1/3rd windows updates
need a reboot after being installed.

> 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).
---
	I'm not sure why the user can't be informed.  If on NT, and not
"lib_on_blacklist" (cygwin1.dll and ilk), then attempt rename of old
lib and creation of newlib.  If successful, continue.  If not, tell user
that they need to reboot after setup completes.

>> 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. 
---
	Not many applications "expect" much of anything having to do
with support libraries other than "they'll be there" and "they'll work".
Calls to most "Dll's", from an application standpoint, are usually
black-box calls through some standard calling interface.  They won't
be likely to care if a DLL version gets bumped on the next process spawn.

	Of course, "ideally", each application lib could have a flag
in it's package info files, as to whether or not a new version can
be loaded into memory while an older version may be present in previous
programs.  Unless they make use of "shared" resources that move with
each DLL generated, I can't see that most applications would "care".

> 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.
---
	Currently, many applications built under Cygwin
already have many "#ifdef CYGWIN"..." dependencies.  I would not want a
"solution" that would add to that list.  I don't see that most applications
would care.

	Another advertised "feature" in XP is automatic, "side-by-side"
execution of specifically versioned DLL's.  I'm not saying Cygwin should
go out of its way to implement this, but theoretically, XP has mechanisms
to deal with a multiplicity of versions of a DLL in memory at the same time.


> The most user-friendly action is guaranteeing that the environment will be
> in a working state after the update. 
---
	I've seen many complaints of failures after an update.  Making
updating "easier" (by not requiring a lengthy-reboot when unnecessary)
I don't see as adding significantly to problems and may reduce problems.
At the very least, a "first" debug step to try after a Cygwin update would
be to make sure the system was "rebooted".  But for users that have
no problems, life would be ever-so-slightly easier.

> The only thing that accomplishes
> that with the current implementation is a reboot.  
---
	IMO, a requirement to reboot is tantamount to a failure.  You've
inconvenienced the user and not necessarily for a good reason.  I don't
know about everyone else, but I don't like rebooting my machine often.  It
takes too long to reboot.  As a result, if an installation tells me I have
to reboot after an install, it may not happen immediately.  My current
XP session has been up over 10 days.    I usually have several applications
running when I do updates.  I don't want to have to terminate all of them
and restart them all in a new session.  Many do not "keep their place".


>> or you can have something that works for most of the people, most
>> of the time, even though it isn't perfect. 
> 
> 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.
---
	Didn't see "below" reference.  Again I don't see that such
a patch wouldn't work for most cygwin users and apps.


> Open-source
> works by scratching your itch, 
---
	That's one way.

> not by getting someone else to scratch it for you.
---
	Not everyone can be a developer on every piece of software they use.
You can't easily be an expert in all domains.  Lobbying or convincing
someone else to implement something in a product they are already
familiar with is far easier than patching a product then meeting
someone else's expectations of what the patch should look like and learning
how to work with that project.

>> ...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.
---
	The fact that it is true, of course, is inconsequential, I suppose.

>  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.
---
	Sadly enough -- I've tried to setup the project base for both
cygwin and setup in the past -- multiple times for each -- cygwin, maybe
2-3 times and setup maybe 3-5 times.  Each time I gave up because after
pulling down the CVS, I could not build the current release.  It always
seemed to be the case that I was missing some tool or include or needed
some special version of something that conflicted with what I already had
installed.  Any time that I asked about the missing "whatevers", I
encountered major** "attitude".

Of course, I am "supposed to know" that various tools and "setups" are
"commonly" used to build or develop "tool X"...  project "inside
knowledge" is completely obvious to those inside the project.  It if
very common for project insiders to believe the various tidbits
required for setup are so common that they should be
known (or easily figured out) by "anyone".  Those beliefs make
it difficult for people to, even, ask questions about setup, let alone
get the questions answered ("Why should I bother answering such an
"obvious-answer" question?).  Some people seem to believe that making
all the mistakes and debugging the build process for yourself is some
"rite of passage".

	It's had more the effect of putting me off my desires to
try to change anything -- poor cost/benefit ratio for me.

> 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 you believe that, you already have defined the problem to be
more complex than you know how to deal with.  I believe a first-order
approximation that works for 90% of the cases is better than no attempt
to continue the install that successfully installs w/o reboot 0% of the
time.

> If Cygwin's implementation of
> fork() can handle renamed DLLs correctly, then I think the patch to setup
> will be accepted without fuss.
---
	Implementing that would seem to be a re-implementation of Windows
multiply-versioned DLL's used "side-by-side".  It's an ugly implementation
in Windows, I doubt it would get prettier in Cygwin.

> Otherwise, I suspect it has little chance of getting in...
---
	The problem can always be defined to make a "fix" sufficiently
difficult as to be "not worth it".  It sounds like that is the case
here.   Why would I be remotely interested in the headache of attempting
to install the build env for setup again and generating a patch that
is politically unpopular because of some people's ideas of "correctness"
(ignoring whether or not it actually "works" for the applications
intended).  Been there, done that, got the headache.

	Different people have different priorities and sensibilities of
how things should work.  My people skills in regards to convincing a
critical and/or hostile code reviewer are woefully inept.  I have to be
an especially masochistic (or optimistic) mood to engage in such an
endeavor.

	It is rare that I feel energetic enough to overcome a programming
problem and political opposition to solving a programming problem.

	FWIW, my speaking up on this issue wasn't so much meant as a
"complaint", but a response to "this is not a setup bug, but a Windows
limitation".  I felt it was incorrect to characterize this as a Windows
"limitation", when it was more accurately characterized as a Cygwin
or setup limitation.

----------------------------------
Christopher Faylor wrote:
 > On Tue, Dec 26, 2006 at 10:01:53AM -0800, Linda Walsh wrote:
 >> 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.
 >
 > Your inexplicable anger aside...
----
	Anger?  Sorry, annoyance, perhaps, but not anger.  It would have to
be a much more trivial issue for me to get angry. ;^)

linda





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