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
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
Igor Peshansky wrote:
Open-source works by scratching your itch, not by getting someone else
to scratch it for you.
Actually getting someone else to scratch that itch sometimes does work! :-P
--
Andrew DeFaria http://defaria.com
Never wrestle with a pig. You both get dirty and the pig likes
On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote:
Igor Peshansky wrote:
Open-source works by scratching your itch, not by getting someone else
to scratch it for you.
Actually getting someone else to scratch that itch sometimes does work!
Right! And, the perfect way to have the itch
Eric Blake wrote:
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
Christopher Faylor wrote:
On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote:
Igor Peshansky wrote:
Open-source works by scratching your itch, not by getting someone
else to scratch it for you.
Actually getting someone else to scratch that itch sometimes does work!
Right! And, the
Andrew DeFaria wrote:
Christopher Faylor wrote:
On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote:
Igor Peshansky wrote:
Open-source works by scratching your itch, not by getting someone
else to scratch it for you.
Actually getting someone else to scratch that itch sometimes
On Wed, Dec 27, 2006 at 08:22:50PM -0600, Andrew DeFaria wrote:
Christopher Faylor wrote:
On Wed, Dec 27, 2006 at 07:17:47PM -0600, Andrew DeFaria wrote:
Igor Peshansky wrote:
Open-source works by scratching your itch, not by getting someone
else to scratch it for you.
Actually getting someone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andrew DeFaria on 12/27/2006 7:17 PM:
Eric Blake wrote:
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
On Wed, Dec 27, 2006 at 10:18:37PM -0700, Eric Blake wrote:
Another question, how is this not a problem for Unix's fork()? Does
Unix's fork also do this by name? Or does it use another mechanism?
Unix's fork is provided natively by the kernel, using copy-on-write
semantics. It is an entirely
Eric Blake wrote:
This part peaks my curiosity. Now I'm not a kernel guy however as you
state fork currently knows which dlls to load for the child by name.
While that makes sense on the outside what if it knew which dlls to
load by number - by open file descriptor number that is?
If only
Larry Hall (Cygwin) wrote:
On 12/25/2006, Linda Walsh wrote:
FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll...
and such while cygwin is running and not had a catastrophe as one
might have
trying to overwrite/update the memory image of a kernel dynamically,
so I
don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Linda Walsh on 12/26/2006 4:14 AM:
Just because something hasn't been tested on unprotected-mode windows
(95, 98, ME) doesn't mean something might not work.
Then I will tell you - renaming in-use files on Windows 9x _does not
Linda Walsh wrote:
The fix I proposed has nothing to do with the cygwin1.dll. As has
been covered previously, since cygwin1.dll and a few other libs are
part of the cygwin kernel, special handling may be needed to upgrade
those dll's. What can be fixed is the installation of .exe and .dll
On Tue, Dec 26, 2006 at 02:38:03PM +, Max Bowsher wrote:
Linda Walsh wrote:
The fix I proposed has nothing to do with the cygwin1.dll. As has
been covered previously, since cygwin1.dll and a few other libs are
part of the cygwin kernel, special handling may be needed to upgrade
those
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
On Tue, 26 Dec 2006, Linda Walsh wrote:
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.
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
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
On 12/26/2006, Linda Walsh wrote:
The excerpt below is a mere subset of the response but is the only one that
raises a point that we haven't already been through at least once in this
thread so I wanted to respond to it.
Not everyone can be a developer on every piece of software they use.
Larry Hall (Cygwin) wrote:
What the file is named is insignificant. When the file is already in
use,
you will run into the situation where the newly installed file is not
moved
into place for use immediately .
---
That is current cygwin behavior. It isn't required to be that way
on NT.
On Mon, 25 Dec 2006, Linda Walsh wrote:
Larry Hall (Cygwin) wrote:
What the file is named is insignificant. When the file is already in
use, you will run into the situation where the newly installed file is
not moved into place for use immediately .
---
That is current cygwin
Igor Peshansky wrote:
And that is exactly the problem -- not the .new suffixes. The way Cygwin
is designed, you cannot have two versions of the Cygwin DLL (think of it
as the kernel) in use at the same time, no matter what the name is. In
Linux, you expect to reboot when upgrading the kernel
On 12/25/2006, Linda Walsh wrote:
FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll...
and such while cygwin is running and not had a catastrophe as one might have
trying to overwrite/update the memory image of a kernel dynamically, so I
don't think it's quite all the end of the
On Tue, Dec 26, 2006 at 01:12:30AM -0500, Larry Hall (Cygwin) wrote:
On 12/25/2006, Linda Walsh wrote:
FWIW, I have replaced the libs like cygwin1.dll, cygintl?.dll... and
such while cygwin is running and not had a catastrophe as one might
have trying to overwrite/update the memory image of a
25 matches
Mail list logo
