Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

> Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com,
>  p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Tue, 22 Dec 2015 12:52:05 -0800
> 
> > If you only longjmp a short while, you have no idea how much stack you
> > freed.  You might as well be just 200 bytes below the level where the
> > stack overflow hit.
> 
> Which is why you setjmp in places where you have a significant stack
> reserve.

There's no way of doing that portably, or even non-portably on many
platforms.  You simply don't _know_ how much stack is left.

> > No, the core isn't in a bad state.  Longjmp is not an abnormal path,
> > its semantics is very simple and clear.
> 
> Longjmp, by itself, is simple and clear. What's unreliable is longjmping
> to Lisp at completely arbitrary points in the program, even ones marked
> "GC can't happen here" and the like.

We longjmp to a particular place, not arbitrary place.

> You say Emacs shouldn't crash.  Fine. We can't make that guarantee
> if the crash recovery code breaks program invariants.

Crash recovery doesn't need to keep invariants.  Or maybe I
misunderstand what invariants do you have in mind.

> If you want to longjmp, you need to do it at certain well-defined
> points only. The current approach is a bug machine.

No, it isn't.  There's a small number of places (2?) to which we
jump.  That's all.

> >> We can gracefully recover from stack overflow of Lisp code. We
> >> cannot recover from stack oveflow at arbitrary points in the C core.
> > 
> > We can and we do.  The recovery has only to be good enough to allow
> > saving your work and exiting.  That's the only goal of that
> > protection: allow the user to exit normally, after saving their work.
> 
> I'd rather rely on autosaves.

It's not reliable enough, because it happens relatively rarely.  Doing
it much more frequently will be an annoyance with many buffers.  And
then there are buffers that don't autosave, but the user might still
want to do something with them if she needs to abandon ship.

> Failing that, we should allocate guard pages, unprotect the guard
> pages on overflow

Thats what the OS is for.  It would be wrong for us to start messing
with page protection etc.  The exception caused by stack overflow
removes protection from the guard page to let you do something simple,
like run the exception handler -- are you suggesting we catch the
exception and mess with protection bits as well, i.e. replace one of
the core functions of a modern OS?  All that because what we have now
is not elegant enough for us?  Doesn't sound right to me.

> and call out_of_memory so that it's obvious Emacs is in a bad
> state. This way, we don't have to longjmp out of arbitrary code
> sequences.

There's no problem longjmping out of arbitrary code sequences.  When
you debug a program, you do that all the time.