[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Proper behaviour for wait()?
From:       Paul Herman <pherman () frenchfries ! net>
Date:       2003-05-31 21:58:51
[Download RAW message or body]

On Sat, 31 May 2003, [ISO-8859-1] Mikko Työläjärvi wrote:

> The only way (except "for historical reasons") the above standards
> excerpts would make sense to me, is if setting the SIGCHLD handler to
> SIG_IGN always makes the system reap child processes,

OpenBSD does this, I believe.

> But I've never seen that behavior described anyware, so that is
> probably not the intent.  Also, it does not work that way on FreeBSD:
> once I've set the SA_NOCHLDWAIT flag, I don't get any SIGCGHLD
> signals.

The closest I can get to deciphering intent is the following
manpage for wait() from The Open Group:

  If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to
  SIG_IGN, and the process has no unwaited for children that were
  transformed into zombie processes, the calling thread will block
  until all of the children of the process containing the calling
  thread terminate, and wait() and waitpid() will fail and set
  errno to [ECHILD].

...which likens setting SIGCHLD to SIG_IGN to SA_NOCLDWAIT when
there aren't any zombies.  In that respect they behave similarly,
and FreeBSD does indeed obey and return -1, so it might not be
unreasonable to infer they behave similarly when there *are*
zombies waiting to be reaped, i.e. return -1 and set ECHILD as does
Darwin & Solaris.

FWIW, Linux (at least 2.4.21 does) seems to be out on its own:
wait() returns success even when BOTH SIG_IGN and SA_NOCLDWAIT are
set.

> And now over to someone who actually knows what they're talking
> about... :)

Indeed!  Anyone?

-Paul.

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]