Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert <eggert@cs.ucla.edu>]

Daniel Colascione wrote:

> Python uses explicit runtime checks, IIRC. HotSpot uses a guard page.

This suggests that Emacs could profitably use either approach to detecting stack 
overflow.

>> We *could* enforce the use by requiring at least one call to QUIT every
>> (say) 100 ms, and by doing the equivalent of 3x C-g when the time limit
>> is exceeded. That'd be useful even without modules.
>
> That's grossly unacceptable. Individual page faults (over which programs
> have little control) can take longer than that.

We are straying into a different topic here, but this is a problem that needs to 
be addressed. If 100 ms is too small, make it 1 s, or enable the timeout only on 
C-g (C-g C-g C-g already can cause longjmp from arbitrary code, so this isn't 
much of a stretch). The point is that Emacs should not freeze indefinitely.

> Besides, modifying all code to fit into Emacs' idiosyncratic model of
> stack overflow detection is unreasonable.

There should be no need to modify library code. We should be able to get this to 
work by having the library wrapper deal with the issue one way or another.

> Please stop repeating the false idea that
> longjmp from arbitrary points in the program to toplevel is harmless.

Neither Eli nor I have said it's harmless. Merely that it works well enough in 
practice. Let's not make perfection the enemy of functionality.

 > the current mechanism does not achieve its goal. It's
 > utterly unsafe even without module code added to the mix.

It's safe enough in practice. You're right that in *theory* it's utterly unsafe, 
but Emacs is a practical program not a theoretical exercise.

Really, the idea that we'll let Emacs crash on stack overflow (merely because 
modules are being used) is a non-starter. We need a better solution.