Once the action is set, delivery should succeed, imo, for each child that would normally have a separate process id due to creation of a child utility environment. I can see older Unix's that didn't track process ids in sigevent structures, because they only implemented signal() and raise(), might have multiple SIGCHLD queued that weren't distinguishable from each other, but this no longer holds. For them reaping multiple may have been considered conforming due to the lack of information. Applications now have to take into account even when they set the handler using signal(), the handler may be triggered by sigqueue() rather than raise(), so is required to have distinguishing information when raise() is called also, at least to the extent of different si_pid values. Conversely, raise() is required to synthesize a siginfo_t structure if the handler is a sa_sigaction type function. >From this a shell might reap multiple child stop / child start pairs for a single child, and I'd hesitate to call that non-conforming, but I believe it should call the action at least once for each, and the child exit. An action doesn't have access to the si_code member, so can't perform different actions based on that, but when si_pid is the same and si_code differ that's enough to keep it unreaped so the action is performed, iow. I feel where the standard should be more explicit, for those interrupts that can have multiple si_code values, is: what is the default si_code value when an application calls raise() for that signo, and whether a handler set by signal() is only triggered when sigqueue() has both that signo and si_code set. Do we need to reserve an si_code value to mean that raise() was used so further information about reason for the signal unavailable? In a message dated 5/10/2017 9:15:56 A.M. Eastern Daylight Time, chet.ra...@case.edu writes:
On 5/10/17 8:47 AM, shwares...@aol.com wrote: > Yes, reception can be blocked for reasons outside a scripts control before > an action is set with trap, but the standard does speak to when signals are > to be raised and delivery attempted. That's all the standard can guarantee. The standard does not guarantee that each child exit will generate a separate SIGCHLD delivery. There is also nothing in the standard that speaks to what a shell, for instance, does when it receives a signal. For instance, there is nothing preventing a shell from reaping multiple children when it receives a single SIGCHLD and running a single instance of the SIGCHLD trap as a result. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
