From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Wed, 30 Sep 2015 15:07:49 +0900 Message-ID: <22027.31797.6292.498407@turnbull.sk.tsukuba.ac.jp> References: <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> <22025.61338.681227.470671@turnbull.sk.tsukuba.ac.jp> <560AFCE3.8090802@lanl.gov> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443675739 19169 80.91.229.3 (1 Oct 2015 05:02:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 05:02:19 +0000 (UTC) Cc: Paul Eggert , Daniel Colascione , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?iso-8859-1?Q?Aur=E9lien?= Aptel , Tom Tromey , Stephen Leake To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 07:02:14 2015 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 1ZhW0S-0001gS-Op for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 07:02:12 +0200 Original-Received: from localhost ([::1]:37884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhW0S-00071p-5q for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 01:02:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhAYa-0001hU-Dt for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:08:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhAYV-0002Kh-Dn for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:08:00 -0400 Original-Received: from turnbull.sk.tsukuba.ac.jp ([130.158.96.25]:40455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhAYV-0002KZ-3g for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:07:55 -0400 Original-Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1ZhAYP-0002D0-4I; Wed, 30 Sep 2015 15:07:49 +0900 In-Reply-To: <560AFCE3.8090802@lanl.gov> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 130.158.96.25 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:190495 Archived-At: Davis Herring writes: > What if we avoid the longjmp call rather than catching it? Define a > (thread-local) signal-raising hook which is also a specpdl barrier. We still have to catch the longjmp. The setjmp *is* the barrier as far as Fsignal and Fthrow are concerned. See unwind_to_catch(). Unless you're proposing to replace unwind_to_catch itself with something that signals "locally" for the duration of the callback. That seems like a very dubious idea to me. Rather, as Daniel has been at pains to say, it's a shame Emacs didn't do that in the first place, as more recently designed languages have managed to do.[1] So if we're going to provide a "no nonlocal exit" unwind_to_catch() for modules, let's use it for Emacs itself, too! > A C++ client, for example, could write AIUI, that's exactly what Daniel and Philipp *don't* want! They want to avoid having the client contain error handling code for Lisp at all, instead managing it behind the API in the Emacs module implementation, and thus making it idiot-proof. Perhaps with some concessions for setting handlers to the DIYers, but there would alway be a safety net. I think this is an illusion, and a dangerous one, for code that is complicated enough to provide a callback interface that accepts Lisp functions. *Especially* if written in crash-prone languages like C and C++. > We might be able to avoid even that by putting the handler into the > emacs_env, Which is what Daniel and Philipp want, and which is what I think is a horrible idea, akin to using `ignore-errors' in basic Lisp functions like `car'. Footnotes: [1] Amusingly enough, even those languages don't always manage to avoid longjmp entirely: Python 3.5 still has two instances of longjmp, one in Modules/fpectlmodule.c, and the other in Modules/readline.c.