[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: On SIGCHLD signal semantics
    In message <>,Marc
    Aurele La France writes:
    > On Tue, 4 Jun 1996 Mark.Hemment@Uniplex.Co.UK wrote:
    > > > The circumstances addressed are when a parent process decides to wait
    > > > for termination of one of its child processes, but does so with
    > > > its SIGCHLD signal handler set to SIG_IGN. If the child process
    > > > terminates while its parent is waiting, this is not a problem. But
    > > > if the child terminates before the parent waits, then the parent
    > > > will be told it has no children (because the kernel has already gotten
    > > > rid of any indication of the child's existence). This can confuse the
    > > > parent process.
    > > wait(2) should fail if a process has no existing unwaited-for child
    > > processes. errno should be set to ECHILD. The parent shouldn't get
    > > confused if it is written correctly.
    > > This is traditional behaviour; I'm sure POSIX.2 hasn't broken it :(
    > What you say is true, but only if the parent isn't ignoring SIGCHLD or the
    > child exits before the parent waits. Thus there's a timing problem when
    > the parent's SIGCHLD handler is SIG_IGN. A wait call by the parent will
    > return one of two things:
    > -ECHILD, if the child exits before the parent's wait call; or
    > the child's pid, if the child exits while the parent is waiting.

    Whoops !
    If this is the behaviour, then it's broken in that it violates the principle of
    least surprise.

    BSD always generates zombies and wait() always succeeds, regardless of the
    disposition of SIGCHLD.
    System V introduced some very dubious semantics where if the disposition of
    SIGCLD (aliased by SIGCHLD in SVR4) is explicitly set to ignore, *no* zombies
    are *ever* generated and wait() will suspend execution until all children have
    exited then return ECHILD. This behaviour was documented as being "unstable"
    or subject to change in SVR2, but is still around in SVR4 and unlikely to
    change now.

    As you state above, the current behaviour is neither one thing nor the other,
    and is not surprising that this causes problems for applications !
    Ironically, early versions of DYNIX/ptx exhibited just such broken behaviour,
    so I'm quite familiar with the problems it causes :-(

    Any chance of this abberant behaviour being fixed (one way or the other) for
    2.0 ?


    Tim Wright, Worldwide Technical Services, | Email:
    Sequent Computer Systems Inc., 15450, |
    SW Koll Parkway, Beaverton, Oregon 97006 | Phone: +1-503-578-3822
    "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

     \ /
      Last update: 2005-03-22 13:37    [W:0.019 / U:14.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site