This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
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