Mail Archives: cygwin/2006/12/27/18:22:33
Linda Walsh <cygwin <at> tlinx.org> writes:
> > 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.
Actually, you are. The ONLY way to make renaming in-use .dlls work is to make
fork() aware of the rename. The way fork() works is that it must reload the
same .dll as the parent process had loaded, and it currently does this BY
NAME. In other words, changing the name of an in-use dll will break the child
process, even if you then install another dll at that location, because the new
dll will have a different layout in memory, and will not reload cleanly. For
your scheme to work, you must teach fork() how to track these renames, and load
the original .dll by its new name, and not the upgraded dll that now lives at
the original name.
> 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.
That statement is false. Reread our explanations - you cannot just change
setup.exe to get renaming to work if a dll is in use, you also have to change
cygwin itself.
>
> 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.
Which WILL BREAK. The new dll (most likely) has different memory layouts.
> This would be
> a technical violation of the POSIX requirement that the address
> space be duplicated. Am I misunderstanding this?
No, you are not. It goes further than violating POSIX - it means the fork()
will flat out fail.
>
> 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.
Actually, it is VERY likely to make a difference. ALL cygwin programs
use .dlls (some more than others, but at least cygwin1.dll), and it has already
been pointed out to you that special casing on the dll names in use is not
technically sound, compared to checking all dlls for whether they are in use.
> But to prevent the possibility
> of it making a difference, cygwin chooses to require a reboot
> to replace those in-use libraries.
Or you could use the current setup.exe snapshot (2.553), which will warn you
that a file is in-use, and let you manually close whatever is using it again,
all before retrying the copy, once again getting you to the situation where you
can reliably avoid a reboot because you did the upgrade while guaranteeing that
nothing in-use was upgraded. In other words, we are already aware of the
issue, and Igor already went to as much effort as he felt reasonable to at
least warn the user that a file is in use and give them another chance, without
forcing a reboot.
>
> 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.
Any programs left running while you upgrade an in-use dll will crash the moment
they try to fork.
> Instead, what would happen is the new process would run with the
> new library that the user has chosen.
Not quite. cygwin1.dll uses a named shared memory region. If two different
versions of cygwin1.dll are both loaded, they interpret that region
differently, and the second one in will fail to run. In other words, you have
made both the old version crash, and the new version fails to load.
> 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.
You got the "painfully" part right, but the "easy" part wrong.
> 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.
Here's where you are wrong. This is an open source project. If it is so easy,
then please submit a patch, tested by yourself, that shows that it was easier
than we thought - we will probably be so impressed by such a patch that we
would install it. What we are trying to tell you is that with our familiarity
of how cygwin works, it will not be trivial, and none of the regular
contributors are bothered enough by this problem to even desire to spend time
trying to tackle it ourselves. We are not opposed to the idea of improving the
upgrade experience, we are just opposed to the effort that we perceive will be
necessary to acheive such a goal when our efforts could be better spent in
other arenas with higher benefit ratios. Whereas if you contribute the patch,
we have minimal effort (mainly the review time of your pre-tested patch). And
if it bothers you so much, even though you don't feel competent to write the
patch yourself, then consider making a financial donation to someone who does
feel competent. The thought of a fair financial remuneration may make the
difference in someone's attitude of whether writing such a patch in your behalf
is worth pursuing.
Disclaimer - don't ask me to write the patch. I still don't have copyright
assignment for cygwin proper, and the only technical solution I see to
implement your ideas involves hacking cygwin1.dll as well as setup.exe.
--
Eric Blake
--
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/
- Raw text -