Re: Handling fatal signals in GNU make

[Paul Smith]

On Sun, 2019-06-09 at 15:47 -0700, Paul Eggert wrote:
> On 6/9/19 3:11 PM, Paul Smith wrote:
> > > 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).
> 
> On platforms lacking sigsuspend, perhaps you could use the self-pipe 
> trick. That is, your SIGCHILD handler simply writes a byte into a
> pipe, and you use select+read+waitpid to turn the SIGCHLD signal into
> a selectable event. See, for example:
> 
> https://stackoverflow.com/questions/282176/waitpid-equivalent-with-timeout

This doesn't seem very portable to Windows either.  gnulib does have a
pipe(2) implementation but it appears it might not work on cygwin? 
Maybe it could work.  I'm a bit skeptical it will be a net gain.

> Doesn't GNU Make already do something like this already with the 
> jobserver pipe? If so, this may be a better solution even on 
> more-standard platforms.

No.  The jobserver pipe stall is a read(), not a wait().  It uses a
different method for handling signals: it does the read on a dup'd
descriptor which is closed by the signal handler.  Or, on systems that
support it, it uses pselect().  On Windows, we use a completely
different method to count jobs (a process shared semaphore IIRC).

I don't think that method can be applied (directly) here.

> If not, sigsuspend might still be a better choice on the more-
> standard platforms that have it, as it should be less hacky.

Well, if we have to implement a "hacky but safe" algorithm anyway I'd
prefer to keep just one implementation, even if it's hacky, than have
two implementations even if one of them is less hacky.

If there's a less hacky and correct algorithm, and a hacky portable
algorithm that works "most of the time", then it's worthwhile to keep
both.

The code in this area is quite a conglomeration of ifdefs, multiple
implementations to try to support ancient systems that don't provide
either waitpid() or wait3(), etc.  I'd hate to make it much worse :).

Maybe the only solution is to break it all down into cleaner APIs so we
can provide OS-specific implementations without all the ifdefs.