Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

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

On 01/03/2016 10:08 AM, Eli Zaretskii wrote:
>> Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sun, 3 Jan 2016 09:49:03 -0800
>>
>>>> You're creating a false dichotomy between safety-critical software and
>>>> everything else. Emacs merely not avionics-grade software does not
>>>> excuse the use of techniques that are both inherently incorrect and that
>>>> add no real value and quite a bit of real danger.
>>>
>>> It's not false dichotomy, it's real.  That you misunderstand this
>>> crucial issue is the root cause of this dispute and of our fundamental
>>> disagreement.  You are applying theory outside of its domain of
>>> applicability.
>>
>> You're not seeing that robustness applies to all software, not just
>> "safety-critical" (however you define that) software, because users
>> depend on software being predictable.
> 
> Robustness comes at a price.  You are asking Emacs and its users to
> pay a heavy price that they don't need to pay, because there are no
> requirements for Emacs to be as robust as safety-critical software.

It's not a heavy price at all. We already protect against runaway lisp
code. If this stack overflow recovery were so important, you'd see other
programs in the same niche (e.g., vim) do it. Why is Emacs alone here?

> Engineering is about compromises: you design and implement your
> systems to meet the requirements with some reasonable margin, but you
> do not implement non-essential features that exert a significant
> impact on what the product can or cannot do.  Doing so is bad
> engineering.
> 
>>>> You have *still* not presented any evidence, not one shred, that we have
>>>> a real stack overflow problem that makes it worth relying on more than
>>>> the auto-save functionality and that makes it worth reaching for unsafe
>>>> and completely undefined behavior.
>>>
>>> Not sure what evidence you are looking for.  Does the fact that 2 not
>>> entirely stupid Emacs developers, each one with years of hacking Emacs
>>> on their record, disagree with you constitute such an evidence?
>>
>> That's not evidence. It's the opinion of two people
> 
> The argument is about assessments.  There could be no facts here, only
> opinions.  What else did you expect?
> 
>> one of whom previously said that the worst side effect of this
>> scheme is a potential memory leak, a statement that suggests that
>> the dangers of this scheme are not being appreciated.
> 
> Only if you think about Emacs as safety-critical piece of software
> that must operate continuously, 24x7.  Otherwise, memory leaks when
> recovering from a disaster that happens very rarely is quite
> acceptable, if it brings other benefits (such as not losing work).

My point isn't that memory leaks are disastrous. It's that the
consequences of this code weren't given due consideration at the time it
was committed.

>>>> All you have is your assertion that Emacs is not safety-critical
>>>> software, we can should use this technique, which you have not
>>>> demonstrated saves anyone anything and which I have demonstrated is
>>>> completely unsafe.
>>>
>>> We are not looking for safe techniques.  That's exactly your mistake.
>>> We are looking for pragmatically helpful techniques.
>>
>> I don't think this technique is even helpful. Quite the opposite,
>> actually, if we start to pollute the module API with some facility for
>> dealing with the result of this awful stack overflow scheme.
> 
> You are not objective, so you exaggerate the risks and dismiss the
> benefits.

I disagree that there *are* significant benefits.

>> *Anything* can happen, and there's no guarantee that what happens is
>> better for the user than an immediate crash. Hell, you can even cause
>> security problems with schemes of this sort.
> 
> Sorry, that's FUD.

No it isn't. When you invoke undefined behavior, anything unpleasant can
happen, and at scale, everything unpleasant will.


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