Date: Wed, 13 Jun 2001 23:40:00 -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: <3B285C40.6500519C@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > :Thanks for this commit, but it works exactly in the way, which > :I wanted to avoid. It is something like "partially submitted and > :not approved by me". Please, could you look once again on it? > :Please please please... Thanks. ;-) > : > :- Hunk #1 from commit adds PS_NOCLDWAIT when SIG_IGN is used for > : SIGCHLD, so if I use > : sigemptyset(&sa.sa_mask); > : sa.sa_flags = 0; > : sa.sa_handler = SIG_IGN; > : sigaction(SIGCHLD, &sa, NULL); > : sigaction(SIGCHLD, NULL, &so); > : I get additional flag SA_NOCLDWAIT in so.sa_flags. None of tested > : systems (Solaris, Unixware, Irix, Linux, Aix) works in this way. > :- If hunk #1 is applied, I see hunk #2 (resetting SIG_IGN to SIG_DFL > : for SIGCHLD) as almost unnecessary, because it is just cosmetic > : change now and behavior in exec() is very different among various > : systems. > > You have to remain consistent, otherwise the exec'd program > might set a signal handler and then restore the original > and suddenly it works differently. I agree. [ ... ] > Your patches look pretty good. Personally I don't think having > the SA_NOCLDWAIT flag show up is a big deal since programs which > use SIG_IGN do not generally know the flag even exists, but I > do agree that we might as well make the interface as compatible > as possible. I really, really object to not setting the SA_NOCLDWAIT flag. At the very least, you need to add a SA_CLDWAIT flag, if you want to not have it show up in this case, and make it show up in the other case. I think doing this would be a mistake, since the intent of the flags is to have (predominantly) OS specific behaviour switches, and a negative switch makes no sense, since you will often set the flags to 0 to avoid getting OS specific behaviours, or accidently setting "whatever's on the stack". Why is the original poster objecting to the flags being set? What if the flag being set was SA_POSIX or SA_SUS2? I don't think it's reasonable to unset the flag, and I don't think it's reasonable to omit _any_ flag in both cases, since there _MUST_ be a way to get historical behaviour. Further, I think that this patch should be limited to the non-compatability code. I don't think that anyone should be nosing around or changing flags values that they dpn't unserstand. The sa_flags = 0 case is a special initialization case, and I view it as being akin to pthreads mutex initializers. While we are at it, no, we should not make sockaddr_in with any old stack garbage in the so-called "unimportant" fields work, just so we can run badly written Linux networking programs. -- 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?3B285C40.6500519C>