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 loading progress Date: Wed, 30 Sep 2015 00:26:49 -0700 Message-ID: <560B8EB9.8030801@dancol.org> References: <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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eEfPoDNDItRNbJGjs3xG8ftoKLeauToPt" X-Trace: ger.gmane.org 1443676086 24117 80.91.229.3 (1 Oct 2015 05:08:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 05:08:06 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Tom Tromey , Stephen Leake To: "Herring, Davis" , "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 07:07:58 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 1ZhW61-0007Yt-Hb for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 07:07:57 +0200 Original-Received: from localhost ([::1]:37944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhW60-0007Sa-W5 for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 01:07:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhBnK-000488-7U for emacs-devel@gnu.org; Wed, 30 Sep 2015 03:27:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhBnG-0001NU-VM for emacs-devel@gnu.org; Wed, 30 Sep 2015 03:27:18 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhBnG-0001N5-JH for emacs-devel@gnu.org; Wed, 30 Sep 2015 03:27:14 -0400 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=V1tu5urup/IeT2ANuzHwXrsYKWolUjIJ57sxqm/wNLQ=; b=bN/0A2119pODdI2LhgWmSpYWmeJ3/nbBQSe6swQUkfqLOOtIU4KTY7/fISaZ9iAOAYx0iflo3Uw8fUSps/3nfMkPqdwDsVuMx8ESU6wqYncRnI6Nff3YJzqQAkqImIitmAZ7cDI7r50ctp6H5qoBR2Ub66uABYb5HTZJ5GFVtzh8c2yLVD+ep6MYs+Kxiu8seym6JxQ5oY5zYdIDDPeecbE26otMNrK+HoyVhJpQ2ufyCnH1OMJv69hOzxIGezitl+FObVl6AZMy1mypOSaeI+822wx+AbPDdtW0e6L77DCKNEdCpF2s5wK8s6mpWhNBv9VM1QGdvcOFva9c+HDs+Q==; Original-Received: from c-24-16-208-239.hsd1.wa.comcast.net ([24.16.208.239] 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 1ZhBmw-0007u1-Ou; Wed, 30 Sep 2015 00:26:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). 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:190500 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eEfPoDNDItRNbJGjs3xG8ftoKLeauToPt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/29/2015 11:56 PM, Herring, Davis wrote: >> We still have to catch the longjmp. The setjmp *is* the barrier as >> far as Fsignal and Fthrow are concerned. See unwind_to_catch(). >=20 > The "struct handler" is the barrier: it's a detail of the current imple= mentation that it contains a jmp_buf (that is always used). >=20 >> Unless you're proposing to replace unwind_to_catch itself with >> something that signals "locally" for the duration of the callback. >=20 > I think by "locally" you mean "by normal function returns only". That'= s not my idea, which is basically to (conditionally) replace > sys_longjmp (catch->jmp, 1); > with > catch->hook (); >=20 > where (according to my straw-man code) catch->hook was populated by the= call to env->error_handle. It's still a non-local transfer, as is neces= sary for the existing calls to unwind_to_catch to possibly work. >=20 >> 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. >=20 > I'm aiming more for idiot-resistant, without the complexity (and overhe= ad) of wrapping every call into Emacs to protect the caller. In other wo= rds, it's a way to recover control (like they want) without significantly= extending the "unsafe" interface (which Stefan wants). >=20 >> 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'. >=20 > 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 reliably get the error_handle and the matching error_unhandle > in one shot (avoiding the possibility of forgetting it, as I did in > my example!). In the trivial case that you just want destructors to > be called and the error to propagate back into Lisp, you could avoid > an explicit try-catch on each module entry point with a wrapper > function template. One practical difficulty of this scheme is that we would have to build Emacs itself with exception unwind information. (Since the default Itanium ABI behavior is to abort if we try to unwind through a stack frame for which we don't have unwind information.) I don't think that would be easy to pull off in the general case, and I don't think it's possible in advance to predict what information we might need to allow stack unwinding to proceed. This scheme leads us further into ABI-dependence. I'd prefer longjmp to a system that required us to let C++ exceptions (with what libstdc++?) propagate through arbitrary Emacs frames. --eEfPoDNDItRNbJGjs3xG8ftoKLeauToPt 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 iQIcBAEBCAAGBQJWC465AAoJEN4WImmbpWBl/m4P/08hbaui/C8POx/9Dn14EIW3 oKGABoQGXei6C5mETE4tpnCFJin8r0MPqQMaJE3xeg5W0ugBFYtPCVNVcy9WOhfm zynII/X4guW6wm/8FxYx/QJ5mrW70Zyq9tTbv7+KGPwtjvw3soA3OyTRpZEyMGNq 3OG9OUT2aE8RDyBKs7BJUifbW9oGCeF5DACM05wsGrhZWSyrQgLq51QEz/1ZSfiq kZZO1O285fJYMwhyfzOl2yyyDR2YkicB4hkMvjtPIV5/jYygLOkcXapSivMH5hKW ezxT5al9GOZwXZ8X4C4m2sh8tNKrPSHhsP4e+QQ6zeE65b7Xth6FUnUNlD/2y7Ql Fzi2UxtXCSJMlY/3UTVfpq6paTlslFwp8z4a7FBrWo+OLM1ANU8J4k9oeV2oL4Na 3SqPUzCkgnzGf6KQKggdIbuXTqaQ+Wwg/Y66HgJvd8xxiy0h681COzBm3FNovky6 7tbDsI9o2Lb5bYj2DuKEbzkuMZm4QTdnlHWLMham3AC+AlZQDAJxoVDgEP4lcN/z OfB8BjhKIq5f35WvJokoLHqXDhZLnQUWkJ1sp70tQnAdqYtMMtC0VJx2UxAdL//G A+7ob11aq1AuaGA5AH7M0cinPjXXL2HeXxMl7ylJsS0WykWZ7q3v1TPA/7yveryu UyHXNCztnm2s0dRG1/gk =VKDG -----END PGP SIGNATURE----- --eEfPoDNDItRNbJGjs3xG8ftoKLeauToPt--