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
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
