Re: Deadlock in signal handler

[Daniel Herring]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make