[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deadlock in signal handler

From: Daniel Herring
Subject: Re: Deadlock in signal handler
Date: Thu, 16 Mar 2017 11:59:36 -0400
User-agent: Alpine 2.20 (LRH 67 2015-01-07)

Hi Paul,

Have you considered using the pattern of using a socket for signal handling? Then the signal handler writes a byte or closes the socket. The other end of the socket detects this using select() or equivalent. Can be a unix pipe or network socket, depending on where the endpoints live. Can support threads, processes, and distributed processes, all in a portable manner.

- Daniel

On Thu, 16 Mar 2017, Paul Smith wrote:

On Tue, 2017-03-14 at 14:19 +0300, Aleksey Fedotov wrote:
I've stumbled upon a peculiar issue, which made make to deadlock.

Yes, this is not good.  One simple (simplistic) fix is to obtain the
translation of fatal error messages early and store them away, and then
use that version when generating output from a signal handler.  This
would avoid the need for calling gettext routines from the handler.

However a better solution would be to rework the signal handling in GNU
make to avoid the problem altogether: that of course is significantly
more effort.  I have been thinking about something similar, though,
because I'd like to have a way for parallel builds to "fail fast": to do
this the various instances of make need to be able to notify each other
if they have a problem.  I'm not suggesting signals for that, but doing
it will require some global state value that is checked during the
normal remake processing loop.  A signal handler could set a value that
was checked in a similar fashion.

Bug-make mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]