> On Tue, 13 Mar 2001, Marc Aurele La France wrote:
>
> > > >> It is perfectly possible to have a handler for SIGCHLD.
>
> > > > ... but not one that can survive exec().
>
> > > No. But if you are the programmer who sets the action for
> > > SIGCHLD to SIG_IGN, disregarding the POSIX warnings, then
> > > you are responsible for what the program does. One way of
> > > making everybody happy would be to set the action for
> > > SIGCHLD back to SIG_DFL after the fork but before the exec
> > > of any child.
>
> > But that's not what POSIX et alia did. They "recommend" that the exec()'d
> > application always reset SIGCHLD, not the exec() caller.
>
> > Backing up a bit, what does it matter where the reset occurs? That
> > decision should be made in terms of impact. Politics aside, it seems a
> > whole lot easier to change implementations, rather than applications.
>
> ... which brings me to the realisation that all sides of this issue agree
> on one thing: that SIGCHLD should be reset to SIG_DFL at some point
> (ditto for SA_NOCLDWAIT). What we disagree on is when. Your suggestion
> above would have it reset by the caller after fork() but before exec().
> POSIX.1, in its rationale, would reset it after exec() by the new process
> image. My position, and Bruce's, is that it be reset during, or by,
> exec().
>
> This consensus, though, is dependent on there being no "real" applications
> that depend on inheriting automatic child reaping.
>
> 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.
>
>
>
I have no objection to this change, and an implementation
was allowed to do this already since the behavior was
unspecified. No portable application could be affected
by this change.
I don't know whether this change is in scope or not.
David Korn
research!dgk
yyy@xxxxxxxxxxxxxxxx
|