Mail Archives: cygwin/2006/12/29/12:30:42
-----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 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.
> 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 Windows had a reliable mechanism that tied open file descriptor
number back to the current filename, even after the file is renamed using
Windows APIs. But it doesn't, so cygwin has to manually track the
filename to file handle mapping by itself. And so renaming a file breaks
cygwin's tracking of that filename.
> I mean wouldn't that
> be a clean way to change fork() to allow it to load the proper, in this
> case, old dlls?
>
> 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 different beast than faking fork on Windows
(for starters, it is orders of magnitude faster). Unix could care less
what shared library filenames were previously opened - the ENTIRE address
space is already faithfully copied to the child process, without having to
reload libraries by name. But Windows is woefully lacking in this area,
so cygwin fakes this by starting the child process, using a shared memory
region to inform the child exactly what the state of memory in the parent
was, then the child must manually reload the same dlls the parent had
open, at the same address. Painfully slow already, and not worth making
slower just to track dll renaming.
>
> (I'm not saying that Cygwin's fork == Unix's fork - indeed perhaps there
> are deep technical reasons why using a file descriptor approach is
> infeasible in Cygwin under Windows).
Indeed, read the docs in CVS to gain an appreciation for the deep
technical magic going on during cygwin's fork():
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?rev=1.5&content-type=text/x-cvsweb-markup&cvsroot=src
- - --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFk1OZ84KuGfSFAYARAiWzAJ90sYlzPu18CvNC8KQSsD1ErHLFOQCgkEzo
KVBCCa6bUxSdB8mea0EiVPQ=
=0avO
-----END PGP SIGNATURE-----
--
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 -