lkml.org 
[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: On SIGCHLD signal semantics
Date
From
In message <Pine.A32.3.93.960604080644.28238A-100000@gpu1.srv.ualberta.ca>,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 ?

t

--
Tim Wright, Worldwide Technical Services, | Email: timw@sequent.com
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    [from the cache]
©2003-2011 Jasper Spaans