Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii]

> From: Philipp Stephani <address@hidden>
> Date: Wed, 23 Dec 2015 16:20:45 +0000
> Cc: address@hidden, address@hidden, address@hidden, 
>       address@hidden
> 
>     > Also, any module with an unbounded amount of computation should call the
>     equivalent of QUIT every now and then. If the module API doesn't let (or
>     ideally, require) modules to do that now, it should. Otherwise it's an
>     Emacs freeze waiting to happen.
>     
>     I agree, but I think it's unrelated to stack overflow. (Though I
>     think we will need to have a module-specific version of QUIT, as long
>     as we keep the constraint of not directly longjmping from module
>     code.)
> 
> There's no harm in providing such a functionality (but of course we can't
> enforce its use).

We will document that in the manual and comment on non-complying code.

> Alternatively modules can run computations in background
> threads and update Emacs state in timer functions.

I'd be very weary of going that way.  Emacs's design doesn't support
such techniques very well, and they will of course multiply
complexity.

>     I think if we adopt the view that the user should save and exit ASAP
>     following recovery from stack overflow (similar to what we expect when
>     we run out of memory), the probability of a "disaster" in this
>     scenario becomes much lower, perhaps negligible.
> 
> The disaster is that longjmps cause undefined behavior in C++ if destructors
> would be skipped (and I don't even want to imagine what would happen to
> higher-level languages such as Java or Haskell).

It is not a disaster if the user saves and exits right after the
recovery, instead of continuing to use the session that hit stack
overflow.  Nothing bad will happen.

>     All in all, I think the current recovery is "good enough", and
>     investing significant efforts into making it slightly better will
>     waste resources that are better applied to more important problems.
> 
> handle_sigsegv already has several cases where the longjmp is skipped: when in
> a GC, when the signal is received from the wrong thread, and when it's not
> guaranteed to be a SO. In those cases Emacs aborts (still autosaving). Why
> can't we do the same if SO is detected while a module function is active? 

It won't auto-save in those cases, and if we try, we will most
probably crash anyway.  Those cases are when we have no better
alternative, and if someone comes up with an idea for solving some of
them, we will definitely consider it.

Making stack overflow do the same is a step backward, because it will
increase the probability of losing work.