Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Tue, 13 Aug 2002 11:34:45 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: vfork / setsid interaction
Message-ID: <20020813153445.GI9193@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <1029248291 DOT 12157 DOT 96 DOT camel AT lifelesswks> <3D591779 DOT 6030906 AT hekimian DOT com> <20020813165230 DOT H17250 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020813165230.H17250@cygbert.vinschen.de>
User-Agent: Mutt/1.3.23.1i

On Tue, Aug 13, 2002 at 04:52:30PM +0200, Corinna Vinschen wrote:
>On Tue, Aug 13, 2002 at 10:28:09AM -0400, Joe Buehler wrote:
>> Robert Collins wrote:
>> 
>> >IIRC According to SUSv2, calling *anything* after [v]fork() other than
>> >exec() may lead to unexpected behaviour. 
>> >
>> >You might like to reference the SUSv2 and see what the expected
>> >behaviour is.
>> 
>> Granted, but compatibility with historical UNIX behavior makes it
>> easier to port things.
>
>Not if compatibility is a big problem.  And the vfork() implementation
>isn't thought to be coincidentally compatible with some random UNIX
>but to be a fast implementation to allow the common cases covered
>by the standards.  Otherwise we could stick with fork() and a vfork()
>which just calls fork().

Before we dismiss the problem, however, I'd like to understand what's
going on.  vfork is basically just a wrapper around spawn.  If there
are problems with a process that is invoked after a vfork then that's
definitely a problem.

If there is a problem with calling setsid in vfork and not having things
correctly restored when vfork "returns", that should be pretty easy to
fix.

cgf