Re: Handling fatal signals in GNU make

[Paul Smith]

On Sun, 2019-06-09 at 14:25 -0700, Paul Eggert wrote:
> 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.

Unfortunately sigsuspend() is not an option since it's not available on
Windows (as far as I can tell).

There are gnulib modules for various signal handling facilities that do
allow porting to Windows (again, as far as I can tell), such as
pthread_sigmask(), sigaction(), etc., but not sigsuspend().

I haven't even considered VMS, which is still active.  Or any of the
most-likely-disused ports such as MS-DOS or AmigaOS.

It might be time to say goodbye to MS-DOS and Amiga and simply suggest
they continue to use the last supported version of GNU make.

> > 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.

I mean that GNU make maintains a list of its outstanding children, so
we must be sure that list is up to date with all children before we
check for fatal signals for the last time before wait(), so any future
signals will be forwarded to all children.

And of course, we need to manage that list (add/remove things) while
signals are blocked (or locked out from being modified by the signal
handler in some other way).