Date: Wed, 13 Jun 2001 23:04:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz> Cc: hackers@FreeBSD.ORG Subject: Re: [Patch?] signal(SIGCHLD, SIG_IGN) is against SUSv2 Message-ID: <3B285400.69B9F60@mindspring.com> References: <20010610183637.A73238@dcse.fee.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Cejka Rudolf wrote: > Ok, I repeat it once again - in the full: If I use > > sigemptyset(&sa.sa_mask); > sa.sa_flags = 0; > sa.sa_handler = SIG_IGN; > sigaction(SIGCHLD, &sa, NULL); > > zombies are still created in FreeBSD, which is against SUSv2. You are correct: --- SIG_IGN If the action for the SIGCHLD signal is set to SIG_IGN, child processes of the calling processes will not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited for children that were transformed into zombie processes, it will block until all of its children terminate, and wait(), wait3(), waitid() and waitpid() will fail and set errno to [ECHILD]. --- It seems signal() in SUS2 has the same issue: --- If the action for the SIGCHLD signal is set to SIG_IGN, child processes of the calling processes will not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited for children that were transformed into zombie processes, it will block until all of its children terminate, and wait(), wait3(), waitid() and waitpid() will fail and set errno to [ECHILD]. --- So it appears that SA_NOCLDWAIT is implied in the flags for both cases. Historical BSD behaviour was to zombie the process on ignore; I'm pretty sure that POSIX left the definition unspecified. According to my reading of my Go Solo 2 book, the SUS2 also leaves it indeterminate whether SA_NOCLDSTOP is implied as well, or if SA_NOCLDSTOP applies to both CONT and STOP of child processes, or just to stop. Very annoying. I think that we will need someone with a copy of POSIX to settle the issue. I'm pretty sure that, given a choice between POSIX and SUS2, POSIX will win any arguments. > > If you hack up signal() to do this, it should be done > > by noting the SIG_IGN and the fact you are using the > > historical compatability signal() wrapper to the POSIX > > interface, and just set the sa_flags bit to do the job. > > And why not to use the second way of the two in SUSv2 specification? > > It is not about (im)possibility. It is about FreeBSD's > conformance to SUSv2 specification (and maybe POSIX?). As I said, someone like Julian E., with a copy of the spec. in hand, will need to weigh in. I believe for POSIX, however, that sigaction() can work as you specify, but signal() can not, since it must retain its historical behaviour... we need a judgement to be sure, since it may have evolved since the last time I had access to a copy. In general, zombie processes in FreeBSD take up only 64 bytes of resource usage holder struct (see the code in exit with regard to rusage), so it's not that big a deal, even if it make "ps" output fairly ugly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B285400.69B9F60>