Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3BF018AD.9000105@ece.gatech.edu>
Date: Mon, 12 Nov 2001 13:45:01 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: cygwin vfork
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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?

--Chuck


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