From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 04 Jan 2016 17:31:40 +0200 Message-ID: <837fjp8ioz.fsf@gnu.org> References: <83mvu1x6t3.fsf@gnu.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> <56899EAC.1030408@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451921513 2693 80.91.229.3 (4 Jan 2016 15:31:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 15:31:53 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 16:31:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aG76p-0006E6-FW for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 16:31:47 +0100 Original-Received: from localhost ([::1]:45430 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG76o-0005qj-J9 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 10:31:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG76k-0005qd-Pd for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:31:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG76f-0001eP-KP for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:31:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG76f-0001eH-HF; Mon, 04 Jan 2016 10:31:37 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3008 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aG76e-0002pS-LF; Mon, 04 Jan 2016 10:31:37 -0500 In-reply-to: <56899EAC.1030408@dancol.org> (message from Daniel Colascione on Sun, 3 Jan 2016 14:20:28 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197584 Archived-At: > From: Daniel Colascione > 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.