Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

On 12/23/2015 06:51 PM, Paul Eggert wrote:
> 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.

For managed code, yes. That's the key distinction that you're missing:
we can prevent runaway stack use in *lisp* code. Doing it for C code is
a mind-bogglingly bad idea, especially given the fundamental
misunderstanding of the dangers involved expressed on this thread. (The
idea that "the worst we can do is leak" reflects a dangerous
misunderstanding of what can go wrong.)

> 
>>> 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.

So, what, we should longjmp out of pthread_mutex_lock if we think it's
taking too long? You can't arbitrarily break program semantics this way,
especially if we're going to run third-party code via modules. Where are
you getting this idea that we need to provide hacky, broken, and
unnecessary crash prevention facilities that other programs don't
(because they're all bad ideas)?

> 
>> 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.

I've already explained the correct way to avoid data loss. Keeping a
damaged Emacs instance alive does nobody any good. You're willfully
invoking undefined behavior to achieve something that's not really
necessary.

> 
>> 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.

Next, we'll be talking about some way to make Emacs not crash on NULL
pointer dereference. This line of reasoning is very scary. We should
prevent *managed* code from crashing at all costs. Trying to impose the
same safety guarantees on C code will do more harm than good. There's a
very good reason other programs don't try to do it. Emacs is alone in
this very bad idea.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]