git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christopher Faylor <me@cgf.cx>
To: Linus Torvalds <torvalds@osdl.org>, git@vger.kernel.org
Subject: Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
Date: Thu, 19 Jan 2006 16:28:56 -0500	[thread overview]
Message-ID: <20060119212856.GA6317@trixie.casa.cgf.cx> (raw)
In-Reply-To: <Pine.LNX.4.64.0601191309130.3240@g5.osdl.org>

On Thu, Jan 19, 2006 at 01:16:17PM -0800, Linus Torvalds wrote:
>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.

>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

  reply	other threads:[~2006-01-19 21:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-18 13:47 cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino Alex Riesen
2006-01-19  5:29 ` Christopher Faylor
2006-01-19  8:59   ` Junio C Hamano
2006-01-19 16:10     ` Christopher Faylor
2006-01-19 20:34       ` Christopher Faylor
2006-01-19 21:16         ` Linus Torvalds
2006-01-19 21:28           ` Christopher Faylor [this message]
2006-01-19 21:44             ` Linus Torvalds
2006-01-19 21:51               ` Christopher Faylor
2006-01-20  1:13     ` [PATCH] fsck-objects: support platforms without d_ino in struct dirent Junio C Hamano
2006-01-20  3:38       ` Christopher Faylor
2006-01-19 10:42   ` cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino Alex Riesen
2006-01-19 18:31     ` Christopher Faylor
2006-01-19 22:08       ` Alex Riesen
2006-01-19 22:51         ` Christopher Faylor
2006-01-19 12:51 ` Petr Baudis
2006-01-19 15:04   ` Alex Riesen
2006-01-19 13:00 ` Petr Baudis
2006-01-19 15:07   ` Alex Riesen
2006-01-20  1:13 ` Junio C Hamano
2006-01-20 13:23   ` Alex Riesen
2006-01-20  1:13 ` [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN Junio C Hamano
2006-01-20 15:01   ` Alex Riesen
2006-01-20 19:10     ` Junio C Hamano
2006-01-20 21:53       ` Alex Riesen
2006-01-21  8:09         ` Junio C Hamano
2006-01-23 13:07           ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060119212856.GA6317@trixie.casa.cgf.cx \
    --to=me@cgf.cx \
    --cc=git@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).