Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert]

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.