X-Spam-Check-By: sourceware.org Message-ID: <45919F7B.8000702@tlinx.org> Date: Tue, 26 Dec 2006 14:17:31 -0800 From: Linda Walsh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Updated cygwin dlls 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 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/