Next release: signal handling rewrite

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Next release: signal handling rewrite

Paul Smith-20
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*.


Reply | Threaded
Open this post in threaded view
|

Re: Next release: signal handling rewrite

Gisle Vanem-2
Paul Smith wrote:

> 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 hope this will improve the situation on Windows where pressing
^C during make (even a 'make -n') will many times just cause make
to hang. It seems another ^C will cause the 'SetConsoleCtrlHandler()'
to simply create another thread that does nothing.

--
--gv