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: Mon, 4 Jan 2016 07:41:27 -0800
> 
> > I think this will emerge as a tremendously complex feature, whose
> > design and implementation will become more and more complicated as new
> > aspects of this come into view.
> 
> Either we already do most of this (as you've discussed previously) or
> it's incredibly complex. You can't have it both ways.

We do have the _functionality_, but its _design_ and _implementation_
are very different: it's much simpler and therefore much more robust
and much less prone to design and implementation bugs that will
definitely lower the overall reliability, instead of making it higher.

> The problem is that the current approach is completely broken, and
> you refuse to acknowledge that it might be causing severe problems
> in a way we'd never hear about.

It's not broken.  It works, for many years.  What you say is simply
not true.

> > Complex backup and recovery
> > procedures are generally a bad idea, because they tend to make the
> > overall reliability lower, not higher, due to problems inherent in the
> > recovery code itself.  So I think doing this is not a good idea.  It
> > certainly isn't a good use of our time and scarce resources.
> 
> What's complex is running arbitrary Lisp code and longjmping to the main
> loop when we *know* Emacs might be in the middle of arbitrary library or
> module code that really might not like its invariants being violated.

No, that's dead simple.  Just look at the code.  You think it's risky,
but risky and complex are two very different things.

> You're attempting to shoot down my proposal

No, I am not.  And even if I did, I can't: you are free to code
whatever you like.

What I'm doing is voicing my opinions on your ideas, which is what
John requested.  He _wanted_ to hear my opinions, after hearing yours.