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 21:37:24 -0700 Message-ID: <55F64F04.9030002@dancol.org> References: <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> <55F62C16.4000105@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cM7uQsnMk1SQ16j2vVo067pG87vtqpv7s" X-Trace: ger.gmane.org 1442205475 20754 80.91.229.3 (14 Sep 2015 04:37:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 04:37:55 +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 06:37:47 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 1ZbLWU-00009a-FP for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 06:37:46 +0200 Original-Received: from localhost ([::1]:38288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbLWT-0000Rn-II for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 00:37:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbLWP-0000Rf-UF for emacs-devel@gnu.org; Mon, 14 Sep 2015 00:37:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbLWM-0004da-OV for emacs-devel@gnu.org; Mon, 14 Sep 2015 00:37:41 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:60286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbLWM-0004cq-81 for emacs-devel@gnu.org; Mon, 14 Sep 2015 00:37:38 -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=C0VW8nZd/VG9z4jcTCaU7OUd1LkeLhdxX4YAwGJioEo=; b=bRyGHJ9ts0i9ErNeIgn2j3YXQRkGuMT+OInvx21VHwvKT0sSdwKPeYeLgSTjmvw/9WiKTYUTTvYa/MnarS2tWeabC9I6RiZ5ImHXfXzbKpvlANvqIjJFwAtIxpzaDe+HaxDQDuCaiStfEuJj/oOT5Aw+QMlVqDrUX8PemOxaVm8+kE8v5PAvt7H1TdGipx2QT3TpuHRdvb/GdpD0YC+UEL8JHDp1+0hmstEhxToYzDUDxDhmBLQnp/DOLhIZpnkeUxM9QHmB7qh1JM5gRqDlFpphFxx4Go3LoiuX6bbBtrx+bpukx6iVc58rhY2m1sIrUbyNCScKdMDcALEdIEjAZw==; 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 1ZbLWC-0006GT-L2; Sun, 13 Sep 2015 21:37: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:189916 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cM7uQsnMk1SQ16j2vVo067pG87vtqpv7s Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/13/2015 09:18 PM, Stefan Monnier wrote: >> 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 Emacs. >=20 > You lost me. >=20 >> I'm objecting to this approach because it's a bug machine, especially >=20 > What is "this approach"? Specifically, I don't think Emacs public module API functions should ever return non-locally. "This approach" means longjmping out to condition-case instead of returning normally from Emacs module API functions. >=20 >> without the Emacs Lisp and GC machinery. >=20 > AFAIK we do have the Elisp and the GC machinery available. Yes, but the whole point of the module system is to access non-Emacs libraries, and these libraries will have its own resource tracking systems, which won't integrate with the Emacs GC core. Longjmp in the Emacs core is convenient: if you want to make an Emacs Lisp string, you can call make_string, and even if the next line of the program longjmps, the GC will take care of releasing the resources associated with that string. 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. I don't imagine most modules will be using Emacs GCed resources for their own data, so they'll have to arrange for cleanups manually. >> It breaks C++ RAII, because there's no way the longjmp out of Emacs >> can run C++ destructors. >=20 > This seems to refer to the "point 5" above. As mentioned it's easy to > 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. If the interface is like internal_condition_case, developers will have to define another C-level function to act as an longjmp barrier, and they'll have to do that for every call from their module to the Emacs core. That's a lot of boilerplate. I'm afraid that developers will skip this boilerplate and just make Emacs API calls directly, leading to the presence of latent bugs that are hard to diagnose and fix. This sloppy approach will appear to work fine, but things can go very wrong in rare circumstances. The problems I foresee are of the form "Emacs crashes when I hit C-g with just the right timing", or "Emacs leaks memory if find-file fails while this module calls it". You can imagine Emacs deadlocking if a module takes a long, Emacs longjmps past that lock's release, and then later (perhaps much later) we try to take that lock and never acquire it.= Sure, it's possible to introduce similar bugs by not checking error codes or some global error flag. The difference is that the danger is better-understood (since many more C programs use error codes or error flags than use longjmp), and we can diagnose the problems arising from a failed error check more reliably than we can diagnose the problems that can arise from a failed stack cleanup. For example, if we use a global error flag, and we see an Emacs module API function called with this error flag set, we can abort immediately, pinpointing the problem. Or we can fail the call, warn the user, or do anything else sensible. We can't even _detect_ the kind of damage produced by missing stack cleanups. --cM7uQsnMk1SQ16j2vVo067pG87vtqpv7s 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 iQIcBAEBCAAGBQJV9k8EAAoJEN4WImmbpWBl310P/2qsKgfEXxIz4s+0TgPFNyTR wE4HafhEwk8s6vJMtrIlNp/XPkupPzcrOZk38u734qDbNkVel9aD3WFZ54VtIiJo XE98nwFAI3jSccduKfLhAGkDHvyQLnK+HGDc0jIjnI5z5fmHCgM4KIqQzhchjjFd BM8617SHvh57689nvGt4UvbZ3IgTbb96S9MyLoju9JX1QDE8TpgHKTK+v9xMFdxw zum568nMtznyE58UYV+oAtfsbVWlQbfK2ebxr7PVXOtA/f4uj4KY3R6Nt9sDE+lk GNe7bjlOVuQD4iEXyFI+nNGQJxPZpI9MM3n3Sj3E+dr3u6+t4gjGtZnh3rkx9C/p WOc7hHSvfbNooIrZMGwE56gmEdN5ViaulfbfK5dFAP37FVkkS/+i8tfdCcsrjHiy S51fwLZ3PyF+ySYO64yqKuHVWlYNzdbQXu8GrGhD84CVGE4gm7vB4Npn4dNy49Q9 05NcAWrcetJhBj5qKdyl/td06BsQ6opesEV8KXlzilwVaf/xgvLr6gK2qgreJ4WB 8icG+aGegRfnAggtSPU7Af4xlBP73Z5I43urUs9pp62RAVv3TKjJAg42qXNrMf0l Kh3S5OXPMGxIER33u24tXfnQL8gI/wX7uvyWvONaPLyalZDfRmGI4P/vTgZXjAS9 ESaf8lSbs79+gaWUCQRX =gz66 -----END PGP SIGNATURE----- --cM7uQsnMk1SQ16j2vVo067pG87vtqpv7s--