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: Sun, 13 Sep 2015 19:08:22 -0700 Message-ID: <55F62C16.4000105@dancol.org> References: <87vbgpk1po.fsf@lifelogs.com> <85mw20gmeo.fsf@stephe-leake.org> <878u97nyjn.fsf@lifelogs.com> <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7fc9x2xhDUTDTx3SLkiRKvnB16ScJGGbL" X-Trace: ger.gmane.org 1442196534 28491 80.91.229.3 (14 Sep 2015 02:08:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 02:08:54 +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 04:08:50 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 1ZbJCM-00081k-Do for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 04:08:50 +0200 Original-Received: from localhost ([::1]:37884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbJCM-0000Lg-1Z for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 22:08:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbJC6-0000LS-LW for emacs-devel@gnu.org; Sun, 13 Sep 2015 22:08:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbJC5-0002R8-IX for emacs-devel@gnu.org; Sun, 13 Sep 2015 22:08:34 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbJC5-0002Qk-5g for emacs-devel@gnu.org; Sun, 13 Sep 2015 22:08: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=60cQHCIPD+nWbgde9zwVjHaBMsGh0ZjskRhF5TfgCTQ=; b=QV6ry4DucMXcTi8TEhqSrSwb9KgJvRs1Z/04NP3eZUkLY3i4Rm0ZxMBq4A3+ZjHz2Ma5GE3pthEW2WVkMhqERiRuKiSDj6g9kF4tIIYul3YW6keUeSWl0g0mS04+Fms15uDKaEKtnBb3BKxxfr7l/L3d101nMjcntYM3dWnQ9B4l++/Bu+vcFwpEB+o1gTsJvBn1lQQvXGJyCPebCy4hqrIQLEbvhmkC6oT+0dwrbbnlRZK4OipxnKbK9tDEL9WnVIGhwueG8hJjYD27Jno6DsCYk5g+/Siphx4Lbi4pCsb18ZtQ8INpOvAZWRWB/VfJ3zKk4qbdNzlPIIV/q5Mhlw==; Original-Received: from [2620:10d:c090:180::1:382e] (helo=[IPv6:2620:10d:c081:1101:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZbJC0-0005Yt-SE; Sun, 13 Sep 2015 19:08:28 -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:189910 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7fc9x2xhDUTDTx3SLkiRKvnB16ScJGGbL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/13/2015 06:58 PM, Stefan Monnier wrote: >>>> It's not possible to skip frames in module code using longjmp, so >>> Why not? >> Because most C code isn't expecting to be unwound. >> Forcing non-local flow control on module code is completely >> unacceptable. Emacs needs to return with an error indication set. >=20 > Hmm... I'm still not sure what's the issue. >=20 > AFAICT, the only odd case I can think of is the following: >=20 > 1- Emacs calls some module code via the new API. > 2- This code (which is Emacs-specific) will know about Fthrow. > 3- It may call some non-Emacs-specific code from some other library.= > 4- This non-Emacs-specific code calls back to some Emacs-specific fu= nction. > 5- This Emacs-specific function calls Fthrow/Fsignal. >=20 > Where the problem only shows if/when we reach point 5. >=20 > This problem can be handled between 4 and 5 by using an appropriate > internal_condition_case. >=20 > Is there some other situation you're thinking of? Nobody is going to consider that case. It'll be hard enough to get developers to properly unwind their own code, especially because we're only talking about a case that's active when things go wrong. Of course we can make non-local control flow work: it works well enough inside Emac= s. I'm objecting to this approach because it's a bug machine, especially without the Emacs Lisp and GC machinery. It breaks C++ RAII, because there's no way the longjmp out of Emacs can run C++ destructors. Rust cleanups, and lots of other runtimes are similarly broken. You're asking developers to cope with Emacs deciding simply never to return from most module API calls. That's okay for Emacs internals, but it's very awkward for code having to talk to Emacs. There's no need to do it that way either. Storing the exception information thread-locally (which means globally unless we ever actually get threads) works with C-ABI semantics, is easier to reason about for developers not used to Emacs internals, and provides just as much error information. --7fc9x2xhDUTDTx3SLkiRKvnB16ScJGGbL 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 iQIcBAEBCAAGBQJV9iwWAAoJEN4WImmbpWBl0ssP/17MKsDfi5/xG2/ZXvpAq8J2 G4WzC6X94Ob+RP149yqZXR/ztWOYHRIqDuzUjgZ0KGy9yzhU+4C1tdgxS4xMdzku emcz7VIUqmQ6JNdQzUvwGkIQ4GucQvN08VGOU8ymVdKqVN2JWgkKh2MvYTseDbnq Oe0Yn60UOAMn2LiHR/3DT9qNnKrr2PQnC4VYNa1AvJ4WfX48txEb2h5vWFtE1sGu mm5lCDRjJQ9//hy+GLEf1Zuc+KuqlGKdvw0aQbtGBJI4qpSIuiWzfIbIUM2Jpqgq 119EZtbiRRAYYt3jT9AuDkWRwtDIyf8j5zPjrvrs2Om5+m6c/OzIi0FtpDZ3d489 euQMmcnN+vgdT3q7SIBbjz6gJV25SKBolM6buCfAFrMGxQLRB4RBkcMmVpPbF45W Z7b2CkpQfQ5qlF0PLWJWh4gOfxCe0cNL22FSIU40MaZHwRUMo98w2KdpDBUQyeAL CHpv2WGEkvNd0emOTA0gJK4pHgS8u+i1dIVbX//JwyAn4ui0he1Igr+6vqfF0tsf XENuGdhVgdnp4Jn2xoLHw76tsQ17ahuV9pjMimKQ3j9jv6tfoG73ucGQ7c9A2JYz OppDPKo25rlZOb/F5IEYe7jnsig72aWleKp6RyOH1jATGWorCgWa8APFO2xlBEBw XuZ7aU829Pms+PMD4mjC =ah6T -----END PGP SIGNATURE----- --7fc9x2xhDUTDTx3SLkiRKvnB16ScJGGbL--