|
| From: | David Boyce |
| Subject: | Re: [bug #51237] Deadlock in Ctrl-C handler on Windows |
| Date: | Mon, 10 Jul 2017 12:24:10 -0700 |
Follow-up Comment #6, bug #51237 (project make):
It's not the exact same problem but it's caused by the same flaw in the make
code: doing lots of work in a signal handler.
What I was hoping to do is change the signal handler to do nothing more than
set a flag saying that the fatal signal was received, and move all the "stuff"
into a separate function that is not a signal handler.
There are lots of issues with having significant work done in a signal
handler. Another bug I just fixed this past weekend is to correct
blocking/unblocking fatal signals, which we need to do only because the signal
handler is mucking about with the child lists.
Then it becomes the responsibility of the mainline code to check the fatal
flag at various times and call the "do fatal stuff" function when it sees the
flag is set.
The question of course is, what are the correct "various times". We can
probably make some fairly good guesses: right before we do something that
might "take a long time".
I guess the real problem is the same one that led to lots of issues with the
jobserver: even if we check immediately before we start to wait for child to
finish the signal could be received in the instant between when we check and
we drop into the wait, and we would have to wait for the child to exit before
we'd notice the fatal signal. I'll have to think about that.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?51237 >
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make
| [Prev in Thread] | Current Thread | [Next in Thread] |