Date: Fri, 15 Jun 2001 01:38:50 -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: <3B29C99A.FD84D3B4@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> <3B2884C1.A938821A@mindspring.com> <200106141708.f5EH8Re24543@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > Umm. Terry, I really have no idea what you are talking about. I am talking about being able to get the previous 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. If FreeBSD is not properly dealing with SIGCHLD (a premise which I disagree with) , which is capable of being worked around in the unmodified API, when is FreeBSD going to correct it's assinine handling of SIGHUP delivery to group leaders not resulting in it being sent to all processes in the group because of incorrect order of revocation? I don't have to check "read" return values on SVR4 or Solaris to handle this case for things like "vi": these systems do the _right_ thing, and send SIGHUP to all processes in the group, and _then_ revoke the tty, instead of revoking the tty, making all the children of the group leader group leaders in their own right, and only delivering the signal to the group leader itself, since the tty has been revoked, so it's not the controlling tty with a HUP condition on it for all the newly elected group leaders. This _can't_ be worked around, without adding stupid checks into all the code for things like tty's, which are never supposed to generate EOF unless you ignore SIGHUP on purpose, or are in cooked mode and type ^D. > :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? I'm talking about obtaining pre-modification behaviour. And if you will read the SUS2, you will see that you can introduce any flag you please, and the programs are not supposed to do anything with the flags they don't understand, since they involve implementation defined behaviour. This whole thing is about as stupid as supporting POSIX file locking semantics "to be standard". -- 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?3B29C99A.FD84D3B4>