This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vfork / setsid interaction


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]