| www.delorie.com/archives/browse.cgi | search |
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |