Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Mon, 12 Nov 2001 16:06:30 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: cygwin vfork Message-ID: <20011112210630.GA25356@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <3BF018AD DOT 9000105 AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF018AD.9000105@ece.gatech.edu> User-Agent: Mutt/1.3.23.1i On Mon, Nov 12, 2001 at 01:45:01PM -0500, Charles Wilson wrote: >Seen on the XEmacs list: > >> In general the cygwin build is slower, I think this is for 3 main >> reasons: >> >> 1) gcc optimization is not as good as MSVC >> 2) The cygwin portability layer adds a lot of overhead especially >> wrt file handling. >> 3) The cygwin implementation of fork-and-exec doesn't jive well with >> the VM size of xemacs. Supposedly a real vfork is in the works for >> cygwin but I can't attest to its functionality. > >Does #3 make any sense? I thought we *had* a real vfork...perhaps it >doesn't work well with large apps? Or is the author just blowing smoke? We have had a sort-of-vfork that should be faster than fork since 1.3.3, I think. No idea what the VM goobledy-gook is referring to. Cygwin's vfork is just black magic that eventually results in running spawn(P_NOWAIT) rather than fork/exec. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/