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 dll's cause unnecessary reboot on NT


Linda Walsh wrote:
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.
---
  Thank you for the observation.  I sometimes don't realize how others
may be perceiving the conversation. I tend to over-focus on specific
parts in some conversations and not address issues that seem
tangential or not related.

Linda, I think we've reach this point here, unless you're willing to try
to understand why "fork()" is important to Cygwin.
---
 I wasn't aware that anyone thought I was 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.  No changes to
cygwin's internals are needed.

I saw a msg. about deleting runtime libraries from a running
process like "bash". I believe this was meant to show that cygwin
simulates POSIX correctness in fork by manually copying and
reloading DLL's from the pre-forked process to the post-fork process's address space. It does this by reloading DLL's from their
original filenames at the time of fork. This suffers from the
"race-condition" that if the original DLL's change (or in this
case, are updated), then the "post-forked" copy of the program
would not be a POSIX correct copy of the original.


In other words, if someone renames and moves a new DLL into place during setup, while a program (ex. bash) is running, then, on fork() cygwin may, _incorrectly_, duplicate the new address space. This would cause a technical violation of the POSIX requirement that the address space be duplicated. Am I misunderstanding this? It comes down to a previously raised point that many (most?)
engineers cannot (or will not) make a trade-off between what is technically correct and doing what user's want. In this case the choice is between a) POSIX correctness -- where processes running before setup would continue to use old libraries after an update
or b), updating the libraries outside of POSIX as the user is
requesting via setup.


   If POSIX correctness was always the best possible solution
we wouldn't see so many Gnu utilities with non-POSIX
behaviors -- like "bash".  The default is to allow _extended_
functionality unless "POSIX_CORRECT" is set in the environment
(or "--posix" is specified on the command line). If this is
the only issue, the couldn't setup do likewise?

   Am I to understand that this is the only issue preventing
acceptance?

No, it's not. You're suggesting that the only reason to not make a change you're arguing for is so that "POSIX" behaviors can be maintained. This is absolutely not the case.

Your response appears to be an edited version of the previous one you sent
yesterday:

<http://cygwin.com/ml/cygwin/2006-12/msg00896.html>

Using it as insight to your comments above, it seems that you're
injecting too much of your displeasure with the outcome of previous
discussions on this list to be able to take in the important aspects
of this one.  That's a shame.  In any case, Eric's reply to your
response from yesterday is still a good answer to even your scaled down
version from today:

<http://cygwin.com/ml/cygwin/2006-12/msg00897.html>

I hope this helps clarify why making 'setup.exe' replace in-use DLLs
without a reboot *does* mean a change to fork().

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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