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?
You yourself wrote that the Bourne shells for OSr5, Linux
and (likely) UnixWare *all* have bugs vis-a-vis SIGCHLD handling.
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."
> 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)'.
> 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)?
> > 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.
|