As Alexandre Julliard wrote:
> > Of course, now that i see that SUSP indeed standardized this oddness,
> > i might change my opinion. Anyway, as demonstrated above,
> > signal(SIGCHLD, SIG_IGN) doesn't work on FreeBSD the way you would
> > expect it to work.
>> Well, if you really tested with the program above then it doesn't
> demonstrate anything, since you don't set the SIGCHLD handler <g>
OK, you're of course right. Well, half of it. ;-) SIGCHLD is being
ignored by default anyway (and that's the main grieve i've got with
that abuse in SVR3: they made explicitly ignoring an implicitly
ignored signal have a different semantic).
Meanwhile i also took the time to review the kernel code, and read the
commit logs. It seems someone indeed has implemented that SIG_IGN
(mis)feature. However, the first implementation of it has been
withdrawn later since it caused kernel panics, and has been redone
afterwards. For that reason, FreeBSD 4.x (which is currently still
the stable branch) didn't inherit that impelementation, and behaves as
i initially explained, while FreeBSD 5.x behaves as you (and SUSP)
expect it. (The requirement of SUSP to behave that way has been the
main reason why someone implemented it at all.) Whereas SA_NOCLDWAIT
has been there all the way since FreeBSD 3.0.
So i still think we should at least have the patch in the FreeBSD
port... (Btw., the reason why i stumpled across it when i saw that
code was that it reminded me of zombies i've once seen for a Wine
application, but i didn't track it down by that time.)
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)