Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

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

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

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

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