[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Next release: signal handling rewrite
From: |
Paul Smith |
Subject: |
Next release: signal handling rewrite |
Date: |
Sun, 05 Jan 2020 16:58:39 -0500 |
User-agent: |
Evolution 3.34.1-2 |
I have a deeper set of followup changes I am working on for a post-4.3
release that rewrite the signal handling in GNU make, so that we do not do
any work in signal handlers other than setting flags. Today, far too much
is done in signal handlers resulting in a number of bugs about hangs etc.
(and I've even seen this happen myself in my systems).
Of course the trick to this is that we have to be regularly checking those
flags since we are no longer relying on asynchronous signal handlers, and
unfortunately GNU make doesn't really have one centralized event loop where
this can be done.
What I'm considering is enhancing the EINTRLOOP etc. macros that I have
added across the code to check all system calls for EINTR and restart them,
so that this macro also checks to see if a signal has been received and if
so, calls a handler function. For almost all signals this is just die()
although of course for SIGCHLD we need something different. This seems
like a straightforward way to quickly detect signals without a lot of code
churn.
I have a simple implementation of this which passes all the unit tests, but
I know for sure that there are race conditions (where if children die at
certain times we won't detect it) so more thought needs to be applied here.
Unfortunately we again find ourselves faced with the frustration of
handling signals and waiting on file descriptors at the same time, that
we've struggled with ever since the jobserver was implemented, *sigh*.
- Next release: signal handling rewrite,
Paul Smith <=