From ajosey@rdg.opengroup.org Tue Apr 10 11:51:30 2001 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.9.2/8.9.2) with SMTP id LAA12437 for ; Tue, 10 Apr 2001 11:51:29 +0200 (CEST) (envelope-from ajosey@rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA11728; Tue, 10 Apr 2001 09:50:48 GMT Received: from skye.rdg.opengroup.org [192.153.166.247] by smtp.opengroup.org via smtpd V1.38 (00/07/25 13:18:13) for ; Tue Apr 10 10:50 BST 2001 Received: (from ajosey@localhost) by skye.rdg.opengroup.org (8.9.3/8.8.7) id KAA13098; Tue, 10 Apr 2001 10:22:50 +0100 Date: Tue, 10 Apr 2001 10:22:50 +0100 From: Andrew Josey Message-Id: <1010410092250.ZM13097@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: n.stoughton@opengroup.org Subject: Finalised PASC 1003.1 Interpretation #132 Cc: stds-pasc-ieee-officers@ieee.org, sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Nick Stoughton From: Andrew Josey, PASC Interpretations Functional Chair Reference: PASC 1003.1 #132 Dear Mr. Stoughton Subject: IEEE Standard 1003.1 Enclosed is the official response for your request for an interpretation of IEEE Standard 1003.1. This response was developed and approved by the members of the 1003.1 Interpretations Committee. To obtain an understanding of the PASC Guidelines for interpretations and their classifications please read http://www.pasc.org/interps/ Please can you confirm receipt of this electronic mail message within ten working days, please carbon copy your response to the IEEE (stds-pasc-ieee-officers@ieee.org) Sincerely, Andrew Josey PASC Functional Chair Interpretations Enclosures Cc: IEEE PASC Officers, SC22 WG15 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1 #132 _____________________________________________________________________________ Interpretation Number: XXXX Topic: SIGCHLD Relevant Sections: 1003.1:1996 p59 lines 161-171 PASC Interpretation Request: ---------------------------- From: Nick Stoughton Date: 2001-03-14 ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): System Interface Standard:IEEE Std 1003.1-1990 (ISO 9945-1:1990) ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 3 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 1003.1:1996 p59 lines 161-171 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): TOPIC: set -e and SIGCHLD This interpretation request is being filed in order to bring this discussion into scope for the Austin Group Revision. The following description is extracted from several emails that have discussed this problem (with thanks to Bruce Korb, David Korn, et al). Question: "Is an implementation that sets the signal handler for SIGCHLD to SIG_DFL in any of the exec family of functions conforming?" >From the email discussion: Bruce Korb: A question occurred to me. If someone does not know that signal handling defaulting to Ignore is different from setting the handling to ignore, then one can inadvertently exec a shell that has SIGCHLD handling set to ignore. I did that myself. If that happens, then how is the shell going to know exit status? If it does not know subprocess exit status the shell won't do anything right. On the other hand, if shells are required to set SIGCHLD handling to SIG_DFL for themselves, then we have a lot of broken shells out there. Not to mention, broken other programs that get surprised when their wait4() calls fail. (It cannot be the fault of the parent process because they cannot always know which calls will spawn a child process. Even if they did, you'll wind up with pug-ugly code and timing hassles trying to dance around calls that may or may not spawn children.) =========== David Korn: System V Release 2 had a signal named SIGCLD and BSD 4.1 has a signal named SIGCHLD which were both referred to as sig child. Both of these were added to earlier version of UNIX so both were added in a way that would not affect existing programs by default. Thus, their default behavior was to behave is if the signal were ignored. Thus, no blocking call would be generated by either of these signals. The SIGCHLD or SIGCLD were used for implementing job control. Since I had implemented job control for both BSD and System V, I pointed out to the standards group that except for SIG_DFL, these signals had different semantics. If a signal handler was set for SIGCLD, then a signal would be generated if there were any unreaped child processes. When the signal handler was caught in System V, it was reset by default to SIG_DFL. However, if a process did not reap a child and instead reestablished the signal handler, it would go into an infinite loop since the signal would be generated again. The SIGCLD SIG_IGN behavior was that the system reaped the child when it completed so that the application didn't have to deal with it. However, I believe that a process blocked in wait() would be awakened, but I am not certain of this. The SIGCHLD signal on the other hand was generated when a child completed if a signal handler was set at that time. No signal would be generated if a signal handler was established while there was waiting children. The SIGCHLD signal was also generated when a child process stopped. I believe that BSD treated SIGCHLD SIG_IGN the same way that it treated SIGCHLD SIG_DFL. The standard adopted the BSD SIGCHLD signal semantics with the following changes: 1. The SA_NOCLDSTOP flag was added so that programs that did not expect a signal on stop would not be affected. 2. The behavior of SIGCHLD was made unspecified when SIG_IGN is specified. 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. 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. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Change the sentence "Signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new process image." to, "Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new process image. If SIGCHLD is set to SIG_IGN it shall be set to SIG_DFL in the new process image." ------------------------------------------------------------------------ Interpretation response ------------------------ The question at hand is whether or not an exec() implementation conforms to the standard if it resets SIGCHLD dispositions from SIG_IGN to SIG_DFL. Two application groupings have been considered in the formulation of this proposed interpretation: - Applications that assume they always inherit SIG_DFL; and - Applications that fork() child processes but never wait() for them, potentially filling up the process table. The standard clearly states that implementation behaviour when SIGCHLD is set to SIG_IGN is unspecified. Yet, the standard also just as clearly states that signals set to be ignored by the calling process image are to remain set to be ignored by the new process image. This "contradiction" is only apparent, but should be clarified. If this is interpreted to mean that SIGCHLD is required to be ignored by the new process image, then applications in the first grouping above cannot conform to the standard without change. However, the implementation retains an ability to control applications in the second grouping. If the implementation resets SIGCHLD to SIG_DFL, applications in the first grouping are allowed to conform to the standard, but the implementation loses its ability to control applications in the second grouping through the SIGCHLD disposition they inherit. This proposed interpretation takes a somewhat "middle-of-the-road" approach. Whether or not an exec() implementation resets SIGCHLD from SIG_IGN to SIG_DFL would be left as unspecified, including the existence or even nature of any mechanism the implementation would use to decide. Rationale: ---------- This proposed interpretation does not invalidate the conformance of existing implementations or applications. It extends the implementation's ability to deal with the issues involved as it sees fit, by not constraining the implementation to a specific behaviour. The implementation may wish to - unconditionally leave SIGCHLD set to SIG_IGN; or - unconditionally reset SIGCHLD to SIG_DFL; or - provide some mechanism, not specified in this standard, to control inherited SIGCHLD dispositions. This proposed interpretation also negates the need to "invent" some other signal disposition for SIGCHLD. Notes to the editor (not part of the interpretation): -------------------- XSH, exec(), DESCRIPTION, page 777 - Line 9894, replace "Signals" with "Except for SIGCHLD, signals" - Line 9896, insert just before "After" at the tail end "If the SIGCHLD signal is set to be ignored by the calling process image, it is unspecified whether the SIGCHLD signal is set to be ignored or to the default action in the new process image." XSH, posix_spawn(), DESCRIPTION, page 1373 - Line 28599, replace "Signals set to be ignored" with "Except for SIGCHLD, signals set to be ignored" - Add new paragraph after line 28602, reading "If the SIGCHLD signal is set to be ignored by the calling process, it is unspecified whether the SIGCHLD signal is set to be ignored or to the default action in the child process, unless otherwise specified by the POSIX_SPAWN_SETSIGDEF flag being set in the spawn_flags attribute of the object referenced by attrp and the SIGCHLD signal being indicated in the spawn-sigdefault attribute of the object referenced by attrp." XRAT, B.2.4.3 Signal Actions, page 3389 Insert new paragraph between lines 3638 and 3639, reading "Whether or not an implementation allows SIG_IGN as a SIGCHLD disposition to be inherited across a call to one of the exec() family of functions or posix_spawn() is explicitly left as unspecified. This change was made as a result of IEEE PASC Interpretation #132, and permits the implementation to decide between the following alternatives. - Unconditionally leave SIGCHLD set to SIG_IGN, in which case the implementation would not allow applications that assume inheritance of SIG_DFL to conform to the standard without change. The implementation would however retain an ability to control applications that create child processes but never call one of the wait() family of functions, potentially filling up the process table. - Unconditionally reset SIGCHLD to SIG_DFL, in which case the implementation would allow applications that assume inheritence of SIG_DFL to conform. The implementation would however lose an ability to control applications that spawn child processes but never reap them. - Provide some mechanism, not specified in this standard, to control inherited SIGCHLD dispositions." Forwarded to Interpretations Group: 12 Mar 2001 Recirculation posted: 28 Mar 2001 Finalized:10 April 2001