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: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Tue, 27 Jul 1999 20:10:29 -0400
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: vfork implementation
Message-ID: <19990727201029.A19877@cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i

Ok.  I've got an experimental vfork implementation working.  I worked
out most of it in the air between Boston and Sunnyvale last week.

The way it works is to fill in a structure with some frame information,
returning from vfork with a value of 0.  The assumption is that the
calling program will 1) not return from the function which called the
vfork (which is true for the BSD vfork implementation) and 2) quickly
call some exec function.

When an exec function is invoked, it checks the above structure to see
if the process is in a 'vforked' state and changes any exec to a
spawn*(P_NOWAIT).  The spawn* function then invokes the "execed" program
as a subprocess and longjmps back to vfork, where the stack is fixed up
and vfork returns with the pid of the newly execed process.

If the exec* function fails, and the program exits, then a true fork is
done which immediately exits with the exit value.  The parent process
then sees the pid of this process on return from vfork.

This implementation has at least one problem.  If you do a 'getpid()' in
the child process you get the pid of the parent not the child.  This is
not insurmountable but I am wondering how big a problem this might be.
Does anyone have any idea?

In benchmarks, this vfork is *at least* twice as fast as a normal fork.

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?

cgf