vfork / setsid interaction

[Joe Buehler]

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