On Tue, 13 Mar 2001, David Korn wrote:
>
> > David Korn wrote,
> > > > > To my way of thinking, the solution is clear: have
> > > > > conforming exec() implementations >always< reset
> > > > > SIGC[H]LD dispositions to SIG_DFL, and SA_NOCLDWAIT
> > > > > to zero. This is the only technically sound solution.
> > > This would violate the standard.
> > And the point being? If no-one can have a conceivable use
> > for a standard behavior and the "standard behavior" requires
> > retroactive fixes to long-standing code, what can the issue be?
> The standard does not require that SIG_IGN behave any differently
> than SIG_DFL. The standard leaves this up to the implementation.
> Any implementation could treat SIG_IGN like SIG_DFL if they want to.
> However, you cannot assume this and as an application writer
> you need to be able to handle this.
Which means that all of the old BSD code needs to be changed to conform to
POSIX. Don't you see the conundrum you are getting yourself into?
> > You yourself wrote that the Bourne shells for OSr5, Linux
> > and (likely) UnixWare *all* have bugs vis-a-vis SIGCHLD handling.
> I wrote ksh and it is aware of SIGCHLD handling and always
> sets a handler for it. Any shell that does not control
> must likely caches SIGCHLD.
> > Is it really the right approach to say that most exec-ing
> > applications that turn off receipt of SIGCHLD with SIG_IGN
> > are broken because once upon a time a mistake
> > was made in the combining of SIGCHLD and SIGCLD?
> > Please say, "No."
> They are not portable. Setting SIGCHLD to SIG_IGN can
> have effects such as not creating zombies.
... and effects on applications they spawn.
> > > If I do signal(SIGCHLD,SIG_IGN)
> > > before the exec, then in the child signal(SIGCHLD,...) must return
> > > SIG_IGN according to the standard.
> > TO WHAT END? That information can be more correctly handed
> > off using command line arguments or `putenv(3)'.
> The end is conformance to the standard. If I were to write a regression
> test that output the setting of the SIGCHLD handler and execed
> this program after setting SIGCHLD to SIG_IGN the standard would
> require that I see SIG_IGN when I ran this program.
No. In fact, no test suite checks for this.
> > > However, the implementation
> > > can treat SIG_IGN as if it were SIG_DFL.
> > > The standard seems to be silent as to whether SA_NOCLDWAIT is set
> > > in the new process or not.
> > Where are the problems in just saying that signal handling
> > is reset to default on exec(2)?
> It contradicts the statement made about signal inheritance in
> the POSIX.1 standard.
Yep. That's the part of the standard at issue here.
> > > > export INHERIT_SIGCHLD_IGNORE=true
> > > > for anyone that really, really wants this incomprehensible
> > > > functionality.
> > > I don't think that environment variables should effect the behavior
> > > of system calls.
> > I am certain that it is wrong for wait() calls to fail because
> > a parent process set SIGCHLD handling to the documented default
> > behavior of being ignored. It is not reasonable to assume that
> > programmers would know that somewhere deep in the POSIX standard
> > there are subtle semantic differences that can have no practical
> > value, but do cause this wait() call failure.
> It is not reasonable for programmer sot set SIGCHLD to SIG_IGN
> because the behavior is unspecified.
Nor is it reasonable to expect them to set it to SIG_DFL.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax: 1-780-492-1729 |
| 352 General Services Building | email: yyy@xxxxxxxxxxx |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 Core Team member. ATI driver and X server internals.
|