Re: Updated cygwin dlls cause unnecessary reboot on NT

[Linda Walsh <cygwin at tlinx dot org>]

Larry Hall (Cygwin) wrote:
> This can be true.  However, to do this effectively, one has to listen and
> learn as well.  Simply restating a point you've made before, if it hasn't
> already been agreed to, does less to convince and more to polarize.  If
> your points aren't agreed upon by the people you're trying to convince,
> it's up to you to take the feedback you're given and figure out how that
> affects your argument.  If you discount the feedback, it doesn't matter
> whether you're on the right or wrong side of the argument.  The fact that
> you don't address the points raised means that you've conceded that 
> there's
> no way to reasonably convince the ones you're lobbying to take up your
> cause.  If that's the case, then further discussion of the point(s) of
> contention is irrelevant and probably even counter-productive.
---
   Thanks for the feedback.  I sometimes don't realize how others
may be perceiving the conversation, as my brain tends to disregard
spurious noise "on the line" (or in the conversation) and I try to
stay on track.
> 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. 

>   No one on this list
> is going to be willing to break "fork()" just to make the experience
> of using "setup.exe" a little easier on XP and later O/Ss.
---
   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.


   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.  This would be
a technical violation of the POSIX requirement that the address
space be duplicated.  Am I misunderstanding this?

   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.  But to prevent the possibility
of it making a difference, cygwin chooses to require a reboot
to replace those in-use libraries. 

   I don't know how often people run setup -- but I don't usually run
it on a daily basis -- maybe not even weeks at a time.  So for when
setup is not running, the above is not an issue.

   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.

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

   It really boils down to my previous assertion that most engineers
cannot make the tradeoff between what is technically correct and
doing what user's want.  In this case the choice is between POSIX
correctness -- where processes running before setup would continue to
use old libraries after an update, or doing what the user running setup
wants -- having the program use the new libraries for any future
calls.  The second isn't strictly POSIX compliant, but it is, *usually*
what the user wants.  If POSIX correctness was the best possible solution
for everyone, you wouldn't see so many Gnu utilities with non-POXIX
behaviors -- like "bash".  The default is to allow the extended
functionality unless "POSIX_CORRECT" is set in the environment
(or "--posix" is specified on the command line). 

   If that was the only technical issue against the user-friendly
behavior, then I /presumed/ that anyone having a need for POSIX
CORRECTNESS would already know about the "POSIX_CORRECT" env var
and the same var could be used to determine setup's "rename"
behavior.  If that wasn't known before, hopefully it is more
clear now.

   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.  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. 
At that point it comes down to the personalities of the implementors.

Do the implementors (or project guardians) have a history of working
to make things easier for users, or do they stand on protocol and
tell users how many ways they, not only, are doing something wrong,
but, additionally, are not even asking for help in the right way?
(Go read some treatise on how to ask intelligent discussions before
you even think to ask for help...etc.).

It is likely to be unrewarding to work in such an environment or to
spend energy to even have discussions like this.  Even if someone
was to implement the changes discussed, the result will have been
bought at too high a price.

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/