Date: Thu, 14 Jun 2001 02:32:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz>, David Malone <dwmalone@maths.tcd.ie>, Peter Wemm <peter@wemm.org>, hackers@FreeBSD.ORG Subject: Re: signal(SIGCHLD, SIG_IGN) patch solving SUSv2 compatibility issue Message-ID: <3B2884C1.A938821A@mindspring.com> References: <200106101845.f5AIje014790@earth.backplane.com> <20010611002050.362CE380E@overcee.netplex.com.au> <20010611115806.A53216@walton.maths.tcd.ie> <20010612095323.A72009@dcse.fee.vutbr.cz> <200106121638.f5CGcOo42940@earth.backplane.com> <3B285C40.6500519C@mindspring.com> <200106140657.f5E6v7i20197@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
> The issue here is first: since we are fixing a bug we might
> as well be as compatible as possible with other platforms and,
> second: on general principles it does make sense to keep SIG_IGN
> operation independant from the newer SA_NOCLDWAIT stuff. A program
> using SIG_IGN has absolutely no expectation that that use will
> effect the sigaction flags, so us modifying the sigaction flags
> accomplish absolutely nothing and could in fact be detrimental of
> some poor sod of a programmer writing code on a FreeBSD box actually
> started depending on the side effect.
You made the point earlier about SIG_IGN vs. SIG_DFL, and
avoiding a side effect there.
The side effect here is similar:
I set SIG_IGN sith signal(), then get the flags (which show a
zero), and then set them with sigaction() -- clearing the bit
that results in the implied side effect behaviour with SIG_IGN.
Further, if I have historically depended upon being able to
seperately deal with SA_NOCLDWAIT so as to be able to reap
childgren whose STOP/CONT I wanted to ignore, then I am
now screwed, and have to handle all or none of them, and
there is nothing I can do to my source code to fix it, short
of adding STOP/CONT handlers and explicitly "handling" the
job control crap.
> So I agree with Cejka - the first patch was pretty good but didn't
> quite hit the mark and now we have a new candidate patch that seems to
> cover all the bases, which David Malone is reviewing and will
> probably commit to -current (and me to stable afterwords).
This breaks software which depends on the historical behaviour,
since there is no way to recover the historical behaviour, and
no way to know that you aren't recovering the historical
behaviour.
At least with a SA_CLDWAIT flag, you could do the ignore and
you would get a compilation warning on half your programs (the
ones that used the now useless SA_NOCLDWAIT).
The ones that didn't and expected to be able to reap with
SIG_IGN are now, of course, screwed even after a recompile,
since there is no missing negative flag to alert them.
8-(.
So how do I get the historical behaviour?
PS: "we might as well be as compatible as possible with other
platforms" ... I await your patches to make Linux code
that doesn't bzero() sockaddr_in work on FreeBSD, since
Linux and Solaris work without the bzero(), but FreeBSD
does not...
PPS: I guess you've finally changed your mind on the SVR4
init and run level stuff?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B2884C1.A938821A>