Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Daniel Colascione <dancol@dancol.org>]

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

On 01/04/2016 07:31 AM, Eli Zaretskii wrote:
>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sun, 3 Jan 2016 14:20:28 -0800
>>
>> That's a reasonable UI, but popping up a window or otherwise displaying
>> UI in-process might not work. Instead, we can fork and exec a new Emacs
>> to interact with the user, and read from a pipe that process inherits a
>> byte telling the crashing Emacs what it should do. All that's perfectly
>> legal to do from an async-signal-unsafe context.
>>
>> The new Emacs has to know *how* to display a message. I think it should
>> be possible to look at the current frame's window system information.
>> For NS and Win32, we just need to know whether it's GUI or a tty.  For
>> X11, we'd just need to extract display. On every frame switch, we can
>> record this information in a simple variable we can read in any
>> async-signal-safe way.
>>
>> Of course the child Emacs has to display something to the user somehow,
>> but we can record the current window-system parameters on every frame
>> switch into async-signal-safe state (say, a global char buffer), so that
>> we can launch the child Emacs with the right display parameters.
>>
>> If the user indicates via the new process that she wants to continue
>> using the broken Emacs, great. We should support doing just that. It'd
>> be nice also to give that child Emacs support for attaching GDB to its
>> parent, actually. Of course it's possible to attach GDB manually, but
>> why not make it convenient?
> 
> 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. 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.

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

You're attempting to shoot down my proposal, which *is* simple,
reliable, and safe, on the grounds that it's *complex*, when the
existing scheme is both unreliable and *infinitely* complex?

From a software engineering perspective, that's just baffling. It's
preferring to use an industrial milling machine with anthrax-coated
turbo-blades instead of a potato peeler. Both can peel a potato, but I
know which one I'd want to use.


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