On Thu, Jan 19, 2006 at 01:16:17PM -0800, Linus Torvalds wrote:
quoted text
>On Thu, 19 Jan 2006, Christopher Faylor wrote:
>>Btw, we're looking to roll out a new release of cygwin which fixes the
>>embarrassing typo in sockaddr_storage.  It is fixed in cygwin
>>snapshots:
>>
>>http://cygwin.com/snapshots/
>
>Quick question for cygwin people (I asked this at an earlier point, but
>I don't think there was any reply): would cygwin prefer using "vfork()"
>over "fork()", or is there no advantage?  With vfork(), I could imagine
>that you might avoid a lot of strange VM games..

Sorry, I missed the earlier question.  I have to get in the habit of
scanning this list more regularly for this type of thing.

Cygwin's vfork implementation currently defaults to fork so it doesn't
matter which is used.

We used to have a vfork which tried to cut down on some of the
substantial overhead that comes with cygwin's fork() but the vfork
implementation eventually grew so complicated that there was eventually
no performance gain and I decided to just yank it and revisit it at
a later point.

So, for now, there is no difference, but, eventually, there might be if
someone masters courage to revisit vfork-on-cygwin.

So, I guess that means that it would be a good idea to switch to vfork
if you were planning for the nebulous future when this made a difference
to cygwin.  Otherwise, I wouldn't bother.

quoted text
>Alternatively, is there anything else we can do that makes things easier?

I'm really committed to making cygwin as much like linux as possible so
that you won't have to make things easier.  The last release added some
stuff which should make building linux easier, in fact.  Also, the
mmap() implementation should be a littler closer to linux.  It is, of
course, a work in progress, though.

The only thing that would speed up process creation in cygwin now is
the use of the windows spawn* family of function calls.  Those could be
used instead of fork/exec but I have a personal aversion to using them
since they are so non-UNIX.  If performance is an issue, however, that
could be something to investigate.

cgf
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html