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 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 obviously don't understand the internals fully however I don't see why
one needs to still think in terms of filenames. If you're fork and you
have a file description, can't you simply read the file from beginning
to end thus making an in memory copy without having to or needing to
know what the filename is for that file descriptor?
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.
Hmmm... I see. This almost makes sense to me - but just barely. Thanks
for the enlightenment.
(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
That may be a little more information than I'm willing to delve into at
this time... OK, I read it. Tis indeed more complex than I initially
thought...
--
Andrew DeFaria <http://defaria.com>
Everything should be made as simple as possible, but no simpler.
--
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/
