Mail Archives: cygwin/2006/12/26/13:02:12
Max Bowsher wrote:
> I believe there is a critical element you have missed.
> In order to perform the rather miraculous emulation of fork(), Cygwin
> needs to reload all the same DLLs that are operating in one process into
> another newly created process. Updating the DLL files on disk whilst
> processes are using them prevents this from happening.
>
> For a simple demonstration of this:
>
> * Start a bash shell
> * Rename any of the DLLs used by bash to something else
> * Try to execute any non-builtin command
> * See the fork failure message
>
----
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.
If you need such critical precision, it sounds like you should be
using a full POSIX environment.
If Cygwin's inability to emulate the full POSIX fork semantics
is at issue, then it seems that the argument of "we can't do it
because it may not be exactly POSIX correct" is weakened already.
Cygwin could continue to display messages to "exit all applications"
whenever you run "Setup", just like every installer still tells you
to shut down all other programs on a machine before continuing an
install.
We aren't talking about something that happens every clock
cycle or even every day. We are talking about taking the most
user-friendly action when the user tries to update an inuse DLL.
You can have semantic excuses why not to do it, or you can do it
and have a friendly user experience, in general. If the user is
truly concerned about correctness, let them assure that no Cygwin
processes are running when performing an upgrade. At least that
is then under the control of the user.
One of the reasons why Open-Source software isn't as user
friendly as OS X or the Windows desktop is prizing anal-correctness
over function. It may fail consistently if you leave it as is and
never allow updating without/reboot (if an inuse DLL is detected),
or you can have something that works for most of the people, most
of the time, even though it isn't perfect. Unfortunately, some
designers don't choose user-friendly, default, behaviors.
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. But the point mentioned by Igor earlier, -- the
code to rename old, inuse dll's and install new ones isn't
difficult if one knows that it can be done and doesn't have a
defeatist attitude about implementing it. Then 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.
> Could this be worked around? Perhaps.
> Is it likely to happen? No, the benefit-to-work ratio is too low.
>
Is this a problem that needs to be worked around? No, the
cost-benefit ratio is too high.
-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/
- Raw text -