Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
>>      The only real change we have to make is to have Emacs longjmp not to
>> >     return_to_command_loop (which might skip module frames), but to longjmp
>> >     instead to the most deeply nested entry point from module code into
>> >     Emacs, which we can set up in advance whenever a module calls into the
>> >     Emacs API.
>> >
>> >Yes, that looks like something we should do, then, to get stack overflow checking working with modules.
> If that means letting modules run arbitrary stack unwinding code on
> the alternate stack, I'm against that.

Likewise. My thought was more to require that the module code's most deeply 
nested frame must be on the main stack, with some (perhaps configurable) amount 
of unused stack space above it, so that any module-specific unwinding would be 
done on the main stack. In other words, the module code knows about stack 
overflow and has methods (either a runtime check on each call as Daniel 
suggests, or guard pages and constraints about module stack frame sizes if this 
works and has better performance) to detect it.

We might also want to put in something to catch trivial stack-overflow infinite 
loops, if they turn into an issue. This would give up on catching a looping 
stack-overflow and would go back to the previous catch. This would break 
destructor-based invariants, but that's often better than crashing. It's akin to 
the existing 3x C-g signal, which breaks invariants all over the place 
(including invariants in module code!) but in my experience is crucial.