From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Herring, Davis" Newsgroups: gmane.emacs.devel Subject: RE: Dynamic loading progress Date: Wed, 30 Sep 2015 06:56:33 +0000 Message-ID: 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>, <22027.31797.6292.498407@turnbull.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443675307 12938 80.91.229.3 (1 Oct 2015 04:55:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 04:55:07 +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: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 06:54:55 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 1ZhVtO-0002xG-8a for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 06:54:54 +0200 Original-Received: from localhost ([::1]:37731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhVtN-0003KO-IX for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 00:54:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhBJy-00089w-UE for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:57:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhBJt-000545-V8 for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:56:58 -0400 Original-Received: from proofpoint4.lanl.gov ([2001:400:4210:400::a4]:56036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhBJt-00053T-M2 for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:56:53 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate4.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id t8U6uX5C009907; Wed, 30 Sep 2015 00:56:33 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id D20E5139A628; Wed, 30 Sep 2015 00:56:33 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from ECS-EXG-P-CH03.win.lanl.gov (ecs-exg-p-ch03.win.lanl.gov [128.165.106.13]) by mailrelay1.lanl.gov (Postfix) with ESMTP id B5FE7139A5EE; Wed, 30 Sep 2015 00:56:33 -0600 (MDT) Original-Received: from ECS-EXG-P-MB01.win.lanl.gov ([169.254.1.251]) by ECS-EXG-P-CH03.win.lanl.gov ([128.165.106.13]) with mapi id 14.03.0224.002; Wed, 30 Sep 2015 00:56:33 -0600 Thread-Topic: Dynamic loading progress Thread-Index: AQHQ7mMjuK7faf6uwEq42jKwBDv6zZ47TqUAgAB4LQCAFsMIgIAAsdUAgADcboCAAPxcgP//o5NQ In-Reply-To: <22027.31797.6292.498407@turnbull.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.165.106.44] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-30_02:2015-09-29, 2015-09-30, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:400:4210:400::a4 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:190493 Archived-At: > We still have to catch the longjmp. The setjmp *is* the barrier as=0A= > far as Fsignal and Fthrow are concerned. See unwind_to_catch().=0A= =0A= The "struct handler" is the barrier: it's a detail of the current implement= ation that it contains a jmp_buf (that is always used).=0A= =0A= > Unless you're proposing to replace unwind_to_catch itself with=0A= > something that signals "locally" for the duration of the callback.=0A= =0A= I think by "locally" you mean "by normal function returns only". That's no= t my idea, which is basically to (conditionally) replace=0A= sys_longjmp (catch->jmp, 1);=0A= with=0A= catch->hook ();=0A= =0A= where (according to my straw-man code) catch->hook was populated by the cal= l to env->error_handle. It's still a non-local transfer, as is necessary f= or the existing calls to unwind_to_catch to possibly work.=0A= =0A= > AIUI, that's exactly what Daniel and Philipp *don't* want! They want=0A= > to avoid having the client contain error handling code for Lisp at=0A= > all, instead managing it behind the API in the Emacs module=0A= > implementation, and thus making it idiot-proof.=0A= =0A= I'm aiming more for idiot-resistant, without the complexity (and overhead) = of wrapping every call into Emacs to protect the caller. In other words, i= t's a way to recover control (like they want) without significantly extendi= ng the "unsafe" interface (which Stefan wants).=0A= =0A= > Which is what Daniel and Philipp want, and which is what I think is a=0A= > horrible idea, akin to using `ignore-errors' in basic Lisp functions=0A= > like `car'.=0A= =0A= But it's not ignore-errors: in my example, the error does propagate, but as= a C++ exception rather than a longjmp. Some easy RAII would let you relia= bly get the error_handle and the matching error_unhandle in one shot (avoid= ing the possibility of forgetting it, as I did in my example!). In the tri= vial case that you just want destructors to be called and the error to prop= agate back into Lisp, you could avoid an explicit try-catch on each module = entry point with a wrapper function template.=0A= =0A= Davis=0A=