Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 21 Dec 2015 22:14:38 -0800
> 
> And even if it were OK for (say) 'cat' to dump core due to
> > stack overflow in a typical environment (which it's not), Emacs is more
> > important than 'cat', because people use it as an interactive text
> > editor and do not want to lose their work.
> > 
> >> we already crash if we overflow the stack while we're GCing.
> > 
> > If so, that's a bug that should get fixed. It's not an excuse to
> > introduce similar bugs.
> > 
> > Really, the idea that it's OK for Emacs to crash is a nonstarter. Emacs
> > should not crash.
> 
> Ideally, we wouldn't have bugs. But we do, and when we hit them, we
> should crash reliably and deterministically if we can't recover
> reliably.

I'm sorry, Daniel, but that kind of philosophy is a non-starter with
Emacs.  Saving the user's work even in some cases is much better than
not saving it at all.  And the current scheme is quite reliable, it
works in many scenarios, though not all of them.

As for bugs that cause fatal errors, Emacs always tried to catch them
and at least auto-save.  This also doesn't work with 100% reliability,
but it saved me my work many times in the past.  It would be a step
backward to give up that, just because it's not bullet-proof.

IOW, crashing reliably is an anti-thesis for Emacs, has been for as
long as I can remember.  And for very good reasons, IMO.  We are not
going to change that.

> The current stack overflow scheme can't recover reliably because it
> doesn't fix maintain invariants. There are ways to fix it --- e.g.,
> we can make our own guard pages, mark them PROT_NONE, and on stack
> overflow, mark them PROT_READ | PROT_WRITE long enough to reach
> eval, *then* signal, but I don't think it's worth it.

Improvements to the current recovery are welcome, although what you
suggest might run afoul of constant changes in the OS internals, so it
could be fragile (or perhaps even impossible on some systems).  Still,
if you have patches to propose, please do, and thanks.

Bottom line, I mostly agree with Paul: we should keep the stack
overflow recovery.  We should also try improving it as much as
possible, in particular wrt modules.  However, I don't think letting
modules run arbitrary stack unwinders, let alone Lisp handlers, when
we detect a stack overflow is a good idea, because the alternate stack
is too small for that, and will run higher risk defeating the
recovery.