On Sun, 25 Mar 2001, Andrew Josey wrote:
> All,
> As a reminder it is not the FC Interps responsibility to propose
> resolutions , we do need volunteers to do that, I can and do try
> to summarise and move the process along when I can.
> On item #132, although we have a proposed solution (and also an an
> extensive set of proposed edits which have been circulated on the Austin
> Group reflector), I have major difficulty relating it to an agreed statement
> of what and where the defect is. Proposing a set of changes will
> not and cannot automatically get a change to the standard, there are
> process guidelines to follow - see below.
> We need to see a proposed interpretation circulated, that succintly responds
> to the problem statement following the guidelines for interpretations , here's
> an example one below, folks may not like it, if you disagree PLEASE PROPOSE
> an alternative.
> Proposed Interpretation:
> The standard is clear.
> The problem that is being presented is the case in which
> a process has SIGCHLD set to SIG_IGN and then execs a new
> process. A conforming application would not set SIGCHLD to SIG_IGN
> since the standard leaves this behavior unspecified. An application
> that does set SIGCHLD to SIG_IGN should set it back to SIG_DFL
> before the call to exec.
This is a mis-statement of the problem presented by IR 132. Beyond a
doubt, an application that sets its SIGCHLD disposition to SIG_IGN is
non-conforming. However, the standard cannot specify any aspect of the
behaviour of non-conforming applications, let alone require them to reset
SIGCHLD to SIG_DFL before invoking conforming applications.
Instead, the issue presented by IR 132 is that the standard currently
requires that this non-conforming behaviour be inherited by the new
process image. To be conforming, the new process image must therefore
reset SIGCHLD to SIG_DFL (or a function) before receiving SIGCHLD signals
and before spawning its own child processes.
Unfortunately, of the plethora of applications that claim conformance, few
do in fact reset SIGCHLD, and therefore few really are conforming.
Another perhaps more striking example is all the old BSD code (that quite
legitimately assumed inheritance of SIGCHLD=SIG_DFL semantics) needs to be
changed for POSIX.1 conformance.
The solution presented by IR 132 would bring back into the fold all
applications that, explicitly or implicitly, assume they inherit
SIGCHLD==SIG_DFL. These include not only the old BSD applications
referred to above, but also the great majority of current applications.
It should be pointed out that all sides of this issue agree that SIGCHLD
should be reset at some point. What we disagree on is when. That
decision should be made in terms of impact. It seems a lot easier to
change implementations than applications. For the reasons stated
above, the standard cannot specify that SIGCHLD be reset by the old
process image. The current standard's rationale would have SIGCHLD reset
by the new process image. The solution presented by IR 132 is to have
SIGCHLD reset to SIG_DFL by the exec() family of functions.
> The standard clearly states that signals set to SIG_IGN by
> the calling process image shall be set to be ignored by
> the new process image. However, the fact that the behavior is
> unspecified, allows an implementation to treat this
> is if SIG_DFL were set and not automatically reap children,
> even if setting to SIG_IGN by the process itself would reap children.
This means the implementation would have to distinguish two different
SIG_IGN: SIG_IGN(1) (the explicit one that causes automatic child process
reaping) and SIG_IGN(2) (the inherited one that leaves zombie child
processes alone). Thus, an exec() implementation would have to change
SIG_IGN(1) to SIG_IGN(2). The difference between the two would be lost to
those applications that save and later restore their SIGCHLD disposition
through signal(). And, there would be no semantic difference between
SIG_IGN(2) and 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.
|