Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On 12/21/2015 10:09 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
>>> That would certainly be easier to implement! But as a user I would not
>>> >find it acceptable.
>> You find it acceptable in most other programs.
> 
> ?!  No, I don't find it acceptable for any program to dump core on stack
> overflow.

Most programs you use don't bother trying to detect or recover from sack
overflow. Why should they? C stack overflow is a programming error. It's
like hitting an assertion failure. Should we try to recover from
assertion failures too?

> 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. 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]