Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
- From
- Christopher Faylor <me@cgf.cx>
- Date
- Jan 19, 2006, 21:28 UTC
- Message-ID
- <20060119212856.GA6317@trixie.casa.cgf.cx>
- 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:
Show 11 quoted lines
>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