[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.
- Re: Sending automatic crash reports to the FSF, (continued)
- Re: Sending automatic crash reports to the FSF, Daniel Colascione, 2016/01/03
- RE: Crash recovery strategies, Drew Adams, 2016/01/03
- Re: Crash recovery strategies (was: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), Eli Zaretskii, 2016/01/04
- Re: Crash recovery strategies, Daniel Colascione, 2016/01/04
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/04
- Re: Crash recovery strategies, Richard Stallman, 2016/01/04
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/05
- Re: Crash recovery strategies, Clément Pit--Claudel, 2016/01/05
- Re: Crash recovery strategies, Eli Zaretskii, 2016/01/05
- Re: Crash recovery strategies, Clément Pit--Claudel, 2016/01/05
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
Eli Zaretskii <=
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/04