Messages in this thread |  | | Date | Tue, 11 Jun 1996 16:05:10 -0600 (MDT) | From | Marc Aurele La France <> | Subject | Re: On SIGCHLD signal semantics |
| |
On Mon, 10 Jun 1996, Tim Wright wrote:
> > For what it's worth, I don't think System V's behaviour is so "dubious". > > It seems the System V folks were trying to address BSD's apparent process > > table bloat when a parent never calls wait.
> Yes, but the only reason for this was the lack of reliable signals and a > non-blocking wait(). BSD had reliable signals and wait3 in BSD 4.2 and > thus didn't need to come up with some very strange semantics to signal > that have tripped people up quite often. > In BSD you simply establish a handler for SIGCHLD and reap any children as > they appear.
In practice, many BSD programmes don't bother setting their SIGCHLD handler, which is why they might not work properly on a System V clone in the unusual case where they inherit SIG_IGN.
> > BTW, pardon my ignorance, but what exactly do expiring children turn into > > if not zombies (in System V)?
> They simply go away i.e. there is no zombie creation. Actually I can't > remember if the SysV code is smart enough to avoid creating a zombie or > if it simplyt does tso then immediately cleans up..
This is essentially what happens in Linux, i.e. the zombie child is cleaned up the next time the parent crosses the kernel/user gate.
> It's somewhat more tricky in DYNIX/ptx because in an SMP kernel the child > has to manipulate the parent process's state and there are some subtle races > to be avoided :-)
This is only a problem if more than one CPU is allowed in the kernel's process data structure at any one time. But this is a separate issue.
Marc.
+----------------------------------+-----------------------------------+ | Marc Aurele La France | work: 1-403-492-9310 | | Computing and Network Services | fax: 1-403-492-1729 | | 352 General Services Building | email: tsi@ualberta.ca | | University of Alberta +-----------------------------------+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +----------------------------------+-----------------------------------+
|  |