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 20:54:26 -0700 Message-ID: <55F644F2.9040303@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> <87fv2hzmw3.fsf@uwakimon.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="EiT6K4agaarhhQFWJXHTENUu6VqlQ58fe" X-Trace: ger.gmane.org 1442202907 17913 80.91.229.3 (14 Sep 2015 03:55:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 03:55:07 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Tom Tromey , Stephen Leake To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 05:54:56 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 1ZbKr1-0005aU-NS for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 05:54:55 +0200 Original-Received: from localhost ([::1]:38171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbKr0-0007Jt-S5 for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 23:54:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbKqm-0007Jg-PC for emacs-devel@gnu.org; Sun, 13 Sep 2015 23:54:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbKqh-00050w-Pe for emacs-devel@gnu.org; Sun, 13 Sep 2015 23:54:40 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:60026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbKqh-00050s-9a for emacs-devel@gnu.org; Sun, 13 Sep 2015 23:54:35 -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=XZZUHdZp5S7dr4ysG1RwdNHzGMBdWlQV/Jq0zuAEljg=; b=NBF9SeuTS2fDgU0US2ESKwOSTpuxMm802QVs6hYuqxW9GvJqGWeiM6mrwdBbvubrY5M0kWD1AY9zr+QQi+067ZZPWsTtivZ2vX450wvjenpRViejLppKiRsxwymlWsE0mayLnk0aducuoiFnxrQ3zgFFpsJp0SLWo5wfC3FBPm8AIUYs8j79ndcwzBVET9O+6CW54eoBkvqsViRX1G+Xz0/7zplRq56cy485fdHAtRG/Irv28zP14+ogaWC1tWQfzFbEdGcuXQkAD+YO23mjFzblJqHmWTWuh0LFRFWom6iw9kD2ske0/ekJBPxhq5Z5HXnNS9ysmB93r1u6s2mseg==; 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 1ZbKqd-00064F-1b; Sun, 13 Sep 2015 20:54:31 -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: <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> 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:189913 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EiT6K4agaarhhQFWJXHTENUu6VqlQ58fe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/13/2015 08:43 PM, Stephen J. Turnbull wrote: > Daniel Colascione writes: > > On 09/13/2015 01:31 PM, Stefan Monnier wrote: >=20 > > >> It's not possible to skip frames in module code using longjmp, so= > > >=20 > > > Why not? > >=20 > > Because most C code isn't expecting to be unwound. Forcing non-local= > > flow control on module code is completely unacceptable. >=20 > "Completely unacceptable" is nonsense. Module code needs to be > written the same way any other Emacs code is written, using various > unwind-protect constructs. Why? There is no positive reason to make Emacs module code resemble Emacs core code. In fact, there's a strong reason to make Emacs module code more conventional, because it'll improve the accessibility of the API, which in turn will increase the quantity and quality of Emacs module= s. The Emacs core code has a lot of baggage. It's not practical to clean it up today, but the module system is a greenfield project. There is no reason to burden it the same way. > If the module wraps external code that > has state that persists past the unwinding, you also need to use the > underlying code's own "unwind protection". We shouldn't break this perfectly reasonable code: void foo() { std::string x =3D something(); emacs_bar(x.c_str()); } longjmp()ing out of emacs_bar prevents any stack unwinding happening, which means that any code that requires stack unwinding for correctness needs to swap every Emacs API call in the equivalent of condition-case. It's cumbersome, especially for any binding that isn't pure C. Can you name an extension system for any other program that longjmps out of its public API functions? --EiT6K4agaarhhQFWJXHTENUu6VqlQ58fe 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 iQIcBAEBCAAGBQJV9kTyAAoJEN4WImmbpWBlqbYP/jr9r88XpDnsEwtfcwVa+lYS kzywl+eXo0k0V+EUgHgsIuaeRx06Hmqv1ETHbtI5xwuyt9aEQx8+DC0B2EdtVkbe hpSfLyCwq1FVEp9K8b5+g7Xb37+PFZusrdHLZA9a6IQw0wN2+pPWiGpdc4umnOQB aZwo0YISwzHswiz1UF2uXs4L6Z2ZqlcoulVL6lupssnj2WCcYQhhHp9kB0/5har9 HzE6Z6TCZVvNV+8zVmmfIkNR7zxnY9Zh/Q3Pyn+B1UYt4v+EmR3Od/sGo0p1+AZB 1SBt1FiSLfzdQf13t3ttCcmDZwmIj0uVGWadNNACiLYxOfKGkJdigIwhyh5mKDbZ flWp9KCl7+iP3teP49VAlBq/1bLI2k0DOwBOALEzKlVIXapki/EOFE9GNukdHK7+ Sm9UhDPLe1t3kIUbp9+6U/aX2EMnmqy1sE15KRGDaCBQlrrgeJiq/kS8w2KhwLVS ag9qDEb8/FG63cxPkWJhvAvzWNft2X6Zuxia/17wSQiMhSx0BLpvU8fpNHeId6uz 2XCKnADZmuiZkdqQhXQMpb079i5qXrjh3y5+JeQvUbEdTm4b6BOtUNVi5ljRkCyi wobBXHfgi6TzUaPypXEJxEUpZYzNuxcotmP1n9A/Jj0QsMIfoJY2VlAg+yUrol7e Bg3S/7jLV3A4lS/NA7fP =WQPv -----END PGP SIGNATURE----- --EiT6K4agaarhhQFWJXHTENUu6VqlQ58fe--