[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling fatal signals in GNU make
From: |
Paul Smith |
Subject: |
Re: Handling fatal signals in GNU make |
Date: |
Sun, 09 Jun 2019 21:29:27 -0400 |
User-agent: |
Evolution 3.32.1-2 |
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.