On Thu, Mar 16, 2017 at 11:59 AM, Daniel Herring
wrote:
> 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
> un
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
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 generatin
URL:
<http://savannah.gnu.org/bugs/?50557>
Summary: Deadlock in signal handler
Project: make
Submitted by: aleksei
Submitted on: Thu 16 Mar 2017 10:37:55 AM UTC
Severity: 3 - Normal
Item Grou
> What do you think about this issue? How can I fix it?
Well titled, precise, concise and horribly plausible. A great write up then.
One that I think deserves a bug report at
https://savannah.gnu.org/bugs/?group=make, if you wouldn't mind. That
fatal_error_signal handler looks repeatedly and
Hello,
I've stumbled upon a peculiar issue, which made make to deadlock. I've
managed to reproduce it only couple of times. Make was building a
project when I send SIGINT to it. However, Make didn't exited and didn't
report any issues.
backtrace showed:
#0 __lll_lock_wait_private () at
../sysde
