X-Spam-Check-By: sourceware.org Message-ID: <4594211D.1090507@cygwin.com> Date: Thu, 28 Dec 2006 14:55:09 -0500 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc4.remi Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Updated cygwin dll's 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> <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> <45916391 DOT 1090906 AT tlinx DOT org> <45919F7B DOT 8000702 AT tlinx DOT org> <4591FA3C DOT 3020402 AT cygwin DOT com> <459413FE DOT 8050500 AT tlinx DOT org> In-Reply-To: <459413FE.8050500@tlinx.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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: 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: 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/