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 22:25:23 -0400
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: vfork implementation
Message-ID: <19990727222523.E20312@cygnus.com>
References: <19990727201029 DOT A19877 AT cygnus DOT com> <379E64FB DOT 21EF15F0 AT vet DOT com DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <379E64FB.21EF15F0@vet.com.au>; from Trevor Yann on Wed, Jul 28, 1999 at 12:03:39PM +1000

On Wed, Jul 28, 1999 at 12:03:39PM +1000, Trevor Yann wrote:
>The process information must be that of the child process. This includes
>the pid, parent process pid, process group id and file handles.

As I mentioned, the process information would not be too difficult to
get right.  I'd forgotten about file handles, though.  They will be
tricky, or possibly even impossible to get 100% correct.  This will be a
serious issue with shells.

>The file handles are fairly tricky. I have seen vfork code that plays
>with file handles, doing dups, closes and (rarely) opens. These changes
>should apply to the actual child process (after the exec), but shouldn't
>affect the parent process.
>
>Signal handling may also be a consideration.

Yup.

>There has to be special handling of exit (and _exit) as well.

Which is already done but more is needed.

>Multithreading is also a problem. I think that if we know that multiple
>threads exist, that we should drop back to fork().

I don't think that we have to worry about multi-threading.  If someone mixes
multi-threading with vfork, then they'll have to figure out the ramifcations
themselves.

>If a vfork implementation is added for B21, then I would like it to be a
>non-default option.

Unless the vfork implementation is very close to a standard implementation
(which mine isn't, currently) it can't be the default.  Currently vfork
just defaults to calling fork.  I guess, I will just turn off my stuff for
now.  I don't have the time to go much further with this but it was an
interesting exercise.

cgf