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
Message-ID: <3D594F9E.1090609@hekimian.com>
Date: Tue, 13 Aug 2002 14:27:42 -0400
X-Sybari-Trust: 968535fb b923d9bf 4738785c 00000109
From: Joe Buehler <jbuehler AT hekimian DOT com>
Reply-To: joseph DOT buehler AT spirentcom DOT com
Organization: Spirent Communications
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin-developers AT cygwin DOT com
Subject: Re: vfork / setsid interaction
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> <20020813153445 DOT GI9193 AT redhat DOT com> <20020813160238 DOT GA11009 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> Btw, if someone (Joe?) can provide a simple test case demonstrating the
> problem I'll be happy to fix it.

It's easy to demonstrate; try this:

int
main(int argc, char* argv[])
{
   int ret;
   ret = fork();
   if (ret == -1) {
     // fork() failed
     printf("unexpected fork() failure!\n");
   } else if (ret == 0) {
     // child
     ret = setsid();
     if (ret == -1) {
       // should be impossible
       printf("impossible setsid() failure!\n");
     }
     ret = vfork();
     if (ret < 0) {
       // vfork failure
       printf("unexpected vfork() failure!\n");
     } else if (ret == 0) {
       // in child
       ret = setsid();
       if (ret == -1) {
	printf("unexpected setsid() failure!\n");
       }
       _exit(0); // I assume this is OK.
     } else {
       // parent
       sleep(2);
     }
   } else {
     // parent
     sleep(2);
   }
   return(0);
}

The first fork()/setsid() should make the child a process group
leader.  The vfork()/setsid() should then fail (er, should NOT
fail, but it does).

The pid does not change in the child after the vfork().  The
setsid() call fails because of this. The vfork() call apparently
changes the child pid on the typical UNIX machine.

Interesting question -- is this pid behavior specified
in a UNIX standard anywhere?  That would sidestep the point
about calling setsid() after vfork() strictly speaking
being illegal.

Joe Buehler