[lkml]   [1996]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |

 \ /
  Last update: 2005-03-22 13:37    [W:0.015 / U:1.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site