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 18:13:56 +0200 Message-ID: <83bn917263.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> <837fjp8ioz.fsf@gnu.org> <568A92A7.9080202@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451924062 12506 80.91.229.3 (4 Jan 2016 16:14:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 16:14:22 +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 17:14:21 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 1aG7lv-0004iv-OW for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 17:14:15 +0100 Original-Received: from localhost ([::1]:45656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7lu-0004lA-Lh for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 11:14:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7ld-0004kd-Rf for Emacs-devel@gnu.org; Mon, 04 Jan 2016 11:14:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG7lZ-0005KH-GZ for Emacs-devel@gnu.org; Mon, 04 Jan 2016 11:13:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG7lZ-0005KD-DJ; Mon, 04 Jan 2016 11:13:53 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3040 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aG7lY-00023K-Nq; Mon, 04 Jan 2016 11:13:53 -0500 In-reply-to: <568A92A7.9080202@dancol.org> (message from Daniel Colascione on Mon, 4 Jan 2016 07:41:27 -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:197608 Archived-At: > Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 4 Jan 2016 07:41:27 -0800 > > > 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. We do have the _functionality_, but its _design_ and _implementation_ are very different: it's much simpler and therefore much more robust and much less prone to design and implementation bugs that will definitely lower the overall reliability, instead of making it higher. > 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. It's not broken. It works, for many years. What you say is simply not true. > > 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. No, that's dead simple. Just look at the code. You think it's risky, but risky and complex are two very different things. > You're attempting to shoot down my proposal No, I am not. And even if I did, I can't: you are free to code whatever you like. What I'm doing is voicing my opinions on your ideas, which is what John requested. He _wanted_ to hear my opinions, after hearing yours.