Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione]

On 01/03/2016 09:39 AM, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Sun, 3 Jan 2016 09:22:32 -0800
>>
>>> IOW, a requirement as fundamental as safety-criticality _does_ affect
>>> the design and the techniques allowed during implementation.  I submit
>>> that this is a fundamental software engineering issue which cannot be
>>> cast away, and as long as Daniel misinterprets it, we can never agree
>>> on anything.  Because in safety-critical software, even a single nasty
>>> crash can be fatal, something that is very far from what Emacs can do.
>>
>> 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.

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

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

The trouble with unsafe mitigations like this one (which inhabits the
same robustness tier as "#define pthread_mutex_lock(l) (void)0 /*LOL
FAST*/") is that errors compound, and once you let undefined behavior
leak in somewhere, you can no longer reason about how the system
operates. It's essential to kill and restart software as soon as you
notice anything going wrong, because only then does reason still apply
to the system.

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

signature.asc
Description: OpenPGP digital signature