Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 3 Jan 2016 08:31:35 -0800
> 
> Daniel Colascione wrote:
> > In 2014, Emacs gained a new path in the SIGSEGV handler that attempts to
> > detect C stack oerflow and longjmp back to toplevel. It's important to
> > note that we don't just longjmp when we're in a safe position: we
> > longjmp from *anywhere*, even if we're, say, in the middle of malloc.
> 
> Although that particular code path may have been introduced recently, for 
> decades Emacs has longjmped from arbitrary locations due to other signals, so 
> adding a longjmp for SIGSEGV does not introduce new issues.
> 
> > The code is fundamentally flawed and cannot be made to work
> > properly on any platform.
> 
> The code is part of Emacs 24.5 and does not appear to be causing problems; at 
> least, I don't recall any bug reports from the field. The other longjmps, which 
> are fundamentally flawed in the same way, have been in Emacs for decades, and 
> also seem to work well enough in practice.

All true.

But we are reiterating a long discussion, where all of this was
already said, and said again, and again, and again.  There's nothing
new left to be said here.

Daniel thinks that Emacs should be designed and implemented as
safety-critical software, where any such techniques are a definite
no-no.  But Emacs is not a safety-critical program, it is allowed to
crash from time to time, even in nasty ways.  It is therefore okay for
such a program to use techniques that make the probability of losing
work lower.  My analysis of this discussion is that this is the
crucial point that Daniel refuses to understand and/or agree to --
that being a non safety-critical piece of software means Emacs can do
stuff that it otherwise would have been prohibited from doing.

IOW, a requirement as fundamental as safety-criticality _does_ affect
the design and the techniques allowed during implementation.  I submit
that this is a fundamental software engineering issue which cannot be
cast away, and as long as Daniel misinterprets it, we can never agree
on anything.  Because in safety-critical software, even a single nasty
crash can be fatal, something that is very far from what Emacs can do.

> One possible way forward here is the approach recommended by GNU libsigsegv. See 
> <https://www.gnu.org/software/libsigsegv/> "About stack overflow handlers". In 
> the past we've avoided libsigsegv's approach because it was considered to be too 
> heavyweight, but it would be safer to do something along the lines that it 
> suggests, or perhaps even to use libsigsegv if available.

Just for the record: the MS-Windows implementation of stack overflow
recovery is a simplification of the Windows code in libsigsegv (the
simplification is possible because libsigsegv, as a general-purpose
library, allows more flexible stuff to be done in the handler).  So at
least on MS-Windows, we already do what libsigsegv does.

> > If we keep this code in Emacs, it sets a precedent for other terrible
> > forms of crash recovery, like silently ignoring writes to NULL ...
> 
> Naah. We're pragmatic, not stupid.

Indeed.