Re: Handling fatal signals in GNU make

[Paul Eggert]

On 6/9/19 12:55 PM, Paul Smith wrote:
> But, in this situation how do we handle wait() where we're waiting for
> children?  Suppose this happens:
>
>   1) make checks for fatal signals and finds none
>   2) SIGTERM is received
>   3) make enters wait() waiting for a child to exit

This is what sigsuspend is for. Perhaps something like the following 
will work for you, to wait for children:

1. Use pthread_sigmask to block SIGCHLD, SIGTERM and any other signals 
you're worried about.

2. You are now in a critical section even though you are not in a signal 
handler. Check for and process any signals received (these will all be 
signals received before step (1) was done). If one of the received 
signals was SIGCHLD, use waitpid with NOHANG to reap exited children.

3. Use sigsuspend to unblock the signals that you blocked in step (1), 
thus exiting the critical section. The call to sigsuspend will wait for 
the next signal to arrive (which can occur because some other child died).

If there are no further children to wait for, and you want to do some 
other processing rather than wait for children, then step (3) can use 
pthread_sigmask to restore the signal set, instead of using sigsuspend.

The code in step (2) is a critical section, in the sense that steps (1) 
and (3) guarantee that step (2) cannot be executed at the same time as a 
signal handler.

> modify the signal handler so
> that in addition to setting a flag it will also signal all the children
> (kill is signal handler-safe), then follow this process:
>
>   a) ensure all children we have started are known
>   b) check for fatal signals
>   c) enter wait()
I'm not sure what "are known" means. That being said, I think this 
alternate approach can be made to work, though it'll be trickier since 
there will be more critical sections.