emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.


From: Eli Zaretskii
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Mon, 04 Jan 2016 17:31:40 +0200

> From: Daniel Colascione <address@hidden>
> 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.  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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]