This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updated cygwin dlls cause unnecessary reboot on NT


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 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 have considered, however, modifying fork so that it just starts a
small "cygfork.exe" and copies all of the real memory that it needs
straight from the parent process - including text segments and data
segments from dlls/exes.

That's a lot of work and I'm not sure that it would be any faster since
you don't get to use the direct OS paging from .exes and .dlls anymore.
And, you'll see a bunch of "cygfork.exe"s running rather than, e.g.,
bash.exe.

(and, of course, I, and others have experimented with copy-on-write
techniques and found that Windows doesn't quite provide what you need)

>> (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

Some of the discussion in the link above is dated.  I'll have to update
that someday.

The way that fork works has not changed too much from Steve
Chamberlain's original implementation in 1996 or so.  I've tweaked the
living daylights out of it but I don't think I've ever managed to
improve very much on the original way of doing things.

cgf

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]