[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling fatal signals in GNU make

From: Paul Eggert
Subject: Re: Handling fatal signals in GNU make
Date: Sun, 9 Jun 2019 14:25:08 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]