Email List: Xaustin-group-lX
[All Lists]

Re: set -e and SIGCHLD

To: yyyyyyyyyyyyyyy@xxxxxx
Subject: Re: set -e and SIGCHLD
From: Marc Aurele La France <yyy@xxxxxxxxxxx>
Date: Tue, 13 Mar 2001 18:03:36 -0700 (MST)
Cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx, yyyyy@xxxxxxxxxxxxxxxxxxx
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.


<Prev in Thread] Current Thread [Next in Thread>