|
From: | Paul Eggert |
Subject: | Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. |
Date: | Sun, 3 Jan 2016 13:02:39 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
Daniel Colascione wrote:
neither you nor Eli have demonstrated in any way that all this complexity is necessary, that we actually have a C stack overflow problem,
I mentioned (1) stack overflow in the regexp code, and (2) stack overflow in C modules; did you miss that? The counterargument for (2) that C modules can crash Emacs in countless ways so let's not worry about stack overflow is not all that convincing. It can be useful for the suspenders of stack-overflow checking to go along with the belt of must-be-perfect modules.
handle_interrupt can call quit_throw_to_read_char only when waiting_for_input is true, which it is only when, well, we're waiting for input, not at arbitrary points in the program.
Ah, good point, so that part of the code should be OK. Still, a few lines earlier we see things like Fdo_auto_save () and fflush (stdout) that can be executed from a Unix signal handler while quit-flag is non-nil. Although this has undefined behavior too, this code has been around for quite some time and I use it more often than I like to admit.
Or can we use a stack guard region [1], and in the signal handler, unprotect the set a global variable in the signal handler, and check the variable on QUIT, and at toplevel, reprotect the guard region. If we segfault again without having reached toplevel, just die. Would that make you happy?
I think something along that lines would suffice, yes. Admittedly I didn't quite follow what you wrote (perhaps some text got elided?). But the main point, as I understand it, is that we needn't worry about having a stack-overflow check inside the stack-overflow handler, because we can insist that the stack-overflow handler be tightly-enough controlled so that it won't recurse indefinitely.
[Prev in Thread] | Current Thread | [Next in Thread] |