Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com List-Unsubscribe: List-Archive: List-Help: , Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Tue, 27 Jul 1999 21:58:45 -0400 To: Earnie Boyd Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: vfork implementation Message-ID: <19990727215845.C20312@cygnus.com> References: <19990728013158 DOT 24033 DOT rocketmail AT web126 DOT yahoomail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990728013158.24033.rocketmail@web126.yahoomail.com>; from Earnie Boyd on Tue, Jul 27, 1999 at 06:31:58PM -0700 On Tue, Jul 27, 1999 at 06:31:58PM -0700, Earnie Boyd wrote: >--- Chris Faylor wrote: >> In benchmarks, this vfork is *at least* twice as fast as a normal fork. > >This is worth including it in the next release. > >> So what do you think? Is this good enough to go into the mythical next >> net release (B21)? Should I make it a cygwin option, i.e. >> CYGWIN=fastvfork? > >Not worth doing, the code I've seen that contains vfork always checks to see if >it's available. If you don't want it just undefine the HAVE_VFORK or what ever >macro. The problem is that cygwin has always implemented vfork but it has always just been implemented as a call to fork. I can't just not implement it and, on reflection, I don't think that the current implementation is quite right. I'll probably implement Sergey's suggestion and then it should be 100% like BSD vfork. cgf