[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Wed, 23 Dec 2015 18:51:23 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]