> > 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 | |
+----------------------------------+-----------------------------------+