From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 4 Jan 2016 07:41:27 -0800 Message-ID: <568A92A7.9080202@dancol.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> <837fjp8ioz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vBaM7P6Ou6Q1oOfXjEOte4HlW9NDj1Maf" X-Trace: ger.gmane.org 1451922111 12101 80.91.229.3 (4 Jan 2016 15:41:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 15:41:51 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 16:41:43 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 1aG7GO-00076w-M3 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 16:41:40 +0100 Original-Received: from localhost ([::1]:45508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7GO-0004AV-1q for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 10:41:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7GG-000416-O5 for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:41:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG7GF-0004tE-O2 for Emacs-devel@gnu.org; Mon, 04 Jan 2016 10:41:32 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7GF-0004t3-FL; Mon, 04 Jan 2016 10:41:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=b4gC/2LT82gHZpW6qySM90wVu2udc7L92yb/FI3CQFk=; b=YtMBqjNWWIOcAncgv3Qp8gm7VLaQ2fH4o4Ha1F+Kbw+eVBQOW5t4SCN0MT7hsQBC36XXy/OFFbNF+R68ErP/ARzCVOiaGvsZ/h1u5isQ44KR3RMfv1U6nDn45KVeFaRFo0JqIC06oCKmdTKFMu3Q4pbA5V+XLOBQQEZAeDh9UAQPHZbOWeIIHnDKY8vsHG9B9O1MLS+UX2vzZI+ZCYg36uuFwFk4MMkvH9dfHWr1RBh1G0aIVxKADkU0AOyYIRuptSHN9OEOI+N81AE1dgE78zZ7ypcC/nXa6POxhiDc2mr0OdRWGAPzBfWI5RUJUorM19T7WqOXa1SudsFmfVfmtg==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aG7GF-0004FW-1c; Mon, 04 Jan 2016 07:41:31 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <837fjp8ioz.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:197594 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vBaM7P6Ou6Q1oOfXjEOte4HlW9NDj1Maf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/04/2016 07:31 AM, Eli Zaretskii wrote: >> From: Daniel Colascione >> Date: Sun, 3 Jan 2016 14:20:28 -0800 >> >> That's a reasonable UI, but popping up a window or otherwise displayin= g >> UI in-process might not work. Instead, we can fork and exec a new Emac= s >> 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 perfectl= y >> legal to do from an async-signal-unsafe context. >> >> The new Emacs has to know *how* to display a message. I think it shoul= d >> 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 th= at >> 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? >=20 > 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? =46rom 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. --vBaM7P6Ou6Q1oOfXjEOte4HlW9NDj1Maf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWipKnAAoJEN4WImmbpWBlxw0P/2GLy40x0noBjWLC7OAhCc7d WCHnJ1oHgYVayCxAw/skHA49LG8/NvkJuCuYMMr2BJ2euF6lIj4N8YtzDGlHQSty /DSyh9iTLshvWPjdKYkJSLuEwPlzNAa3PIyUKisqv7uCVdQZIoYdwnkwfKYdyNDz 0hDrJdfNqQjdyG4RyuBE1Y2m6w82AIfiTq1UZXtbWqOiX0rbqPoewMjIAC+6M3CZ QSjkXWRVxojsJJCMEL/zl//vxVy8i93XLtzcXCe5j2VD7c358e61HkJANwCBa/CZ 7ymjWOiNwfas8pAqLStxmkLYRaQokEGgdyiPj4C+f/bP9cJuAdkQkteILr91Iqvx 4ptrwTDtjd1o3FIgrrjn8to4S0YMY1OTpyZf1sK0I6Gr+SaKSe1ZBQIzNm00PWT7 eR2j+3GRtyU70YaNzmzIxED4iy/O1N8HWI4OPZEj3O+rnN/dCpmgcEy/MRjPv4FT B56QhovnacUSzFlxTqwT9kzC12kOh1FSaDWmKkfcPoA3yKyTe4IhLcZb7i0SK8Pg ED1c13OBvg5ZAy4/FB3zZYbtTUo0wlMJeOPM/jfVpVjHo5aMo1FbGU789RwKhYx2 kFOzZgjIHCmMPLJynHwZZ52hSp9GI0ZWmIi6nF1u0hgRlgteeT2sMkfwvSBoqugw 3HlELsAOKlLbtV2MPc1i =LyJC -----END PGP SIGNATURE----- --vBaM7P6Ou6Q1oOfXjEOte4HlW9NDj1Maf--