: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.
Umm. Terry, I really have no idea what you are talking about.
:> 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.
What historical behavior? That FreeBSD was not properly
dealing with SIG_IGN when every other UNIX does?
So you are saying that your interest is in writing software
that only works under FreeBSD? I'm sorry, I don't buy it.
: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).
Again, I have no idea what you are talking about here. Why
would we want to introduce a non-standard flag?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message