> 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.
> 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.
>
> > 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.
>
> > 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.
>
> > > 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.
>
David Korn
research!dgk
yyy@xxxxxxxxxxxxxxxx
|