Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

> Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org,
>  tzz@lifelogs.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 22 Dec 2015 08:39:53 -0800
> 
> 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.

Is that practical?  One problem that I, as a module developer would
face, is to estimate the amount of stack I'd need for unwinding.
Where do I begin?

Then there are all the stack frames below the module, which belong to
some Lisp someone else wrote -- who will be responsible for ensuring
those other unwinders don't need large amounts of stack space that
might be unavailable at stack-overflow point?

Stack overflow detection on modern systems uses hardware assistance
and processor exceptions to detect overflow with no runtime
penalties.  Doing the equivalent in application code is bound to incur
additional processing, which will slow down code, right?  If you think
about manipulating the guard pages to make them resizable, are we sure
enough of the supported platforms allow that?

IOW, I simply don't see how this could be practical

Stack overflow, like any other fatal error, are very infrequent events
in Emacs.  Hitting stack overflow when some module runs is even rarer.
Why is it a disaster to fail to invoke the unwinders in those cases?
My warm advice to users is to save and exit immediately after the
recovery anyway, so I fail to see why some resource leak is a grave
problem.  Anyone who continues a session that recovered from stack
overflow is playing with fire anyway.