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: Mon, 14 Sep 2015 08:14:06 -0700 Message-ID: <55F6E43E.9030502@dancol.org> References: <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DgPfJrjmFwQRCCXXk9Dr8q9aH2pc88XWG" X-Trace: ger.gmane.org 1442243725 6327 80.91.229.3 (14 Sep 2015 15:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 15:15:25 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Tom Tromey , Stephen Leake To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 17:15:16 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 1ZbVTQ-0001Lo-Jt for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 17:15:16 +0200 Original-Received: from localhost ([::1]:41520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbVTP-0000zl-UK for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 11:15:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbVSm-0000js-TV for emacs-devel@gnu.org; Mon, 14 Sep 2015 11:14:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbVSj-0005lt-HL for emacs-devel@gnu.org; Mon, 14 Sep 2015 11:14:36 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:35539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbVSj-0005k1-5q for emacs-devel@gnu.org; Mon, 14 Sep 2015 11:14:33 -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=nOo0ET5j6EaDa+vRUJl3sSweEvmH8XBrHpptTwImBHk=; b=Qo6LqbXOALvEaDNTOT5NBhuJFaEgpCTf+U1y/rdjctnACaJj56mYPyZEcC4Ya8up21inUte603PDU7UojJI0wtX3igRtX32sN1Ttv8iAdKWT6ojkdR0OHhji+AfvCQA5c7xmgZTMu3/sIadKiVi5HcCHJmsn//KlIY0aLR/7aVMNp2rTGQYXwvln5UkTK+9QdPLHqo17mb4sCx8tUp2qMu8xE3NxUyUmr/ROTRmw54bu9ahdqhvuaM22Gz9LQyjq8U75zbI6PJnoufk4lFazBV8bjBmKI9+/LuKIsaUEyQ51mft+yY4iiihP/ZBGK2K+2+VLJ6KV2LOAOefexaE6Tg==; 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 1ZbVSM-0000vy-M9; Mon, 14 Sep 2015 08:14:10 -0700 X-Enigmail-Draft-Status: N1110 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:189947 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DgPfJrjmFwQRCCXXk9Dr8q9aH2pc88XWG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why are you so insistent on using non-local exits for error handling? Representing errors more conventionally is cheap. If there's even a small chance that I'm right about the safety and maintainability advantages of using purely local exits, why not err on the side of caution? AFAICS, there's no advantage to using non-local exits and plenty of risks. On 09/14/2015 05:14 AM, Stefan Monnier wrote: >> Yes, but the whole point of the module system is to access non-Emacs >> libraries, >=20 > But the issue only comes up once these non-Emacs libraries call back to= > Emacs functions (i.e. step 5 in my example). So only those calls need > to be protected somehow from non-local exits. Calls back to Emacs functions will be fairly common, because modules use these functions to manipulate Emacs data on behalf of their own callers. Any of these functions can quit. What you're imagining will be a rare case will in fact be common. I also don't think it's correct that the Emacs-specific module code will work properly in the presence of modules. You're supposing too much patience and knowledge on the part of third-party module authors who'll want to provide bindings not only for Emacs, but for other systems as wel= l. >> and these libraries will have its own resource tracking >> systems, which won't integrate with the Emacs GC core. >=20 > Right, just like the libraries we currently link to from core Emacs > (libxml, libgnutls, libX, ...). They *very rarely* call back to > Emacs functions. >=20 >> Imagine if you had to individually arrange to call free on both the >> success and error paths for every string you wanted to allocate --- >> that's what life will will be like for module authors. >=20 > No. Only for those who choose to use use manually-managed data. Who will be common, because the entire point of writing modules is to work with the _non_-Emacs world. I can imagine one module that has both non-trivial calls back into Emacs and quite a bit of internal state in suitable for management with Emacs primitives. It's called Python. Modules aren't going to be limited to small data-centric thngs like libjpeg, and we shouldn't design the extension system in a way that discourages more complex kinds of integration. >> I don't imagine most modules will be using Emacs GCed resources for >=20 > I do. >=20 > And I think we should encourage them to do so. For that reason we want= > to add finalizers, for example. >=20 >>> This seems to refer to the "point 5" above. As mentioned it's easy t= o >>> prevent the longjmp from escaping back into the surrounding non-Emacs= >>> (e.g. C++) code. >> I agree that it's possible. I don't agree that it's easy. >=20 > Of course it is. We already do that in Emacs's core with things like > safe_call. safe_call blindly suppresses errors. Errors from module-invoked functions to propagate normally from the perspective of surrounding Lisp code. --DgPfJrjmFwQRCCXXk9Dr8q9aH2pc88XWG 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 iQIcBAEBCAAGBQJV9uQ+AAoJEN4WImmbpWBl4pwP/0faOns3+s3g0fMtVXPRRW+/ Ts4yOYlk3brenOjExhkisp71hq6wqycRylNqE3i2XDrScUWoIiSFIVPeAxLEafyp IfgV/pn87dOWItPbyxxVCt1A1L7L7YYj/xj4bAAH8p4/WmcaKS2JeXShFSgmVoG9 RQmy1SAzK0yjLf0PBkqKSN2Pf1Ugs8pbXHQs7PSqsEgyNd8r5xXqhhMUO+7+qYlR +52WE6COF5i8u3EitOoT3tcTR3vSmvzgEyS892+2rm9KzCOHiKL4RAOhocXCQv94 QtQxp/q7o/c5idHJ5SVrnhN+ye6qulLksuTf9Wvo4wH28W+/J7hs5N7YZva92ieo LydKUSIlBS1RbTpwRZ/vzMPNEnnE6FifP029ttGKtcBy76ecFxkP+IjbNLSJN1yo mybVg8fuxaB9sP0Weg3vprrJMtU3NHidgqOC4GsulYzfO9F2Q1uIYsT7PQ+PMF1L iMt4j1YGp4HNyohLGhFiFZVaQmiJyq8As0OpV8k0sLtykOi25NTl2J5MipLMbrwV uwVY8vbt0Fvyckqylr7PIR9Y0EYvAfT7kvpJ+WsYe+F2EQuUO9iJ6WnP9VHYXL8g T9OSSjhRGvkXwS8xS17SHXzlnPKwSlzXqn1AcrRnlu1Godc+rYQmb+2rWfMCQUMN lQm/+BxurBdmpc1qaHQU =LHUH -----END PGP SIGNATURE----- --DgPfJrjmFwQRCCXXk9Dr8q9aH2pc88XWG--