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 modules: MODULE_HANDLE_SIGNALS etc. Date: Wed, 23 Dec 2015 19:11:02 -0800 Message-ID: <567B6246.4070708@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XltA7vj8ink7bXAnartuMF5uXP31wlIuB" X-Trace: ger.gmane.org 1450926693 2561 80.91.229.3 (24 Dec 2015 03:11:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 03:11:33 +0000 (UTC) Cc: Emacs Development To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 24 04:11:32 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 1aBwJP-0001y9-Qb for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 04:11:32 +0100 Original-Received: from localhost ([::1]:58677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwJO-0008MK-W1 for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 22:11:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwJB-0008MC-L6 for Emacs-devel@gnu.org; Wed, 23 Dec 2015 22:11:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBwJA-0006It-F6 for Emacs-devel@gnu.org; Wed, 23 Dec 2015 22:11:17 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:41455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBwJA-0006IZ-3b for Emacs-devel@gnu.org; Wed, 23 Dec 2015 22:11:16 -0500 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=ml1QFHslbanyOcrvTDgIEwC4sGT0eGTiAS2w6wUJ7mQ=; b=J3k6aAjRevK91lqZVjG/oA6B4zeeixP//z6K08eMX03WI4uRI+KJIiRqBpvYrdesjsoBtOwyskTE51m9AZ2epSy2sNMw6SMM/lrtGPFeMm0IgXeNKsYsOKNwBQ3pmxUUWZ83Jof8r/+mJMkUTxzVxEUjgrrdNryU3u0GGRUaOdiyKz5HXJ01RwArnYIh3Ig4gnxM7MlSy4SJcTZYDZyh4vxFU+bMiDEl8YJ+gOqqn2Kj86EITkrVSpiOiabdowQ9pMHr+7XBdwA9/JX9Tw4b1QRnaY1jjGihxBfwL57o839lF8/0d0zcp+TiwxS0TFuhcQsTviJ0QvupyZtkkIGImQ==; Original-Received: from [2620:10d:c090:180::31bb] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aBwJ2-0000Bf-TJ; Wed, 23 Dec 2015 19:11:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <567B5DAB.2000900@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:196747 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XltA7vj8ink7bXAnartuMF5uXP31wlIuB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2015 06:51 PM, Paul Eggert wrote: > Daniel Colascione wrote: >=20 >> Python uses explicit runtime checks, IIRC. HotSpot uses a guard page. >=20 > This suggests that Emacs could profitably use either approach to > detecting stack overflow. For managed code, yes. That's the key distinction that you're missing: we can prevent runaway stack use in *lisp* code. Doing it for C code is a mind-bogglingly bad idea, especially given the fundamental misunderstanding of the dangers involved expressed on this thread. (The idea that "the worst we can do is leak" reflects a dangerous misunderstanding of what can go wrong.) >=20 >>> We *could* enforce the use by requiring at least one call to QUIT eve= ry >>> (say) 100 ms, and by doing the equivalent of 3x C-g when the time lim= it >>> is exceeded. That'd be useful even without modules. >> >> That's grossly unacceptable. Individual page faults (over which progra= ms >> have little control) can take longer than that. >=20 > We are straying into a different topic here, but this is a problem that= > needs to be addressed. If 100 ms is too small, make it 1 s, or enable > the timeout only on C-g (C-g C-g C-g already can cause longjmp from > arbitrary code, so this isn't much of a stretch). The point is that > Emacs should not freeze indefinitely. So, what, we should longjmp out of pthread_mutex_lock if we think it's taking too long? You can't arbitrarily break program semantics this way, especially if we're going to run third-party code via modules. Where are you getting this idea that we need to provide hacky, broken, and unnecessary crash prevention facilities that other programs don't (because they're all bad ideas)? >=20 >> Besides, modifying all code to fit into Emacs' idiosyncratic model of >> stack overflow detection is unreasonable. >=20 > There should be no need to modify library code. We should be able to ge= t > this to work by having the library wrapper deal with the issue one way > or another. >=20 >> Please stop repeating the false idea that >> longjmp from arbitrary points in the program to toplevel is harmless. >=20 > Neither Eli nor I have said it's harmless. Merely that it works well > enough in practice. Let's not make perfection the enemy of functionalit= y. I've already explained the correct way to avoid data loss. Keeping a damaged Emacs instance alive does nobody any good. You're willfully invoking undefined behavior to achieve something that's not really necessary. >=20 >> the current mechanism does not achieve its goal. It's >> utterly unsafe even without module code added to the mix. >=20 > It's safe enough in practice. You're right that in *theory* it's utterl= y > unsafe, but Emacs is a practical program not a theoretical exercise. >=20 > Really, the idea that we'll let Emacs crash on stack overflow (merely > because modules are being used) is a non-starter. We need a better > solution. Next, we'll be talking about some way to make Emacs not crash on NULL pointer dereference. This line of reasoning is very scary. We should prevent *managed* code from crashing at all costs. Trying to impose the same safety guarantees on C code will do more harm than good. There's a very good reason other programs don't try to do it. Emacs is alone in this very bad idea. --XltA7vj8ink7bXAnartuMF5uXP31wlIuB 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 iQIcBAEBCAAGBQJWe2JGAAoJEN4WImmbpWBl0WYP/iNW6tEL+URzxzx3rjTbc9oc 00AzgBbFpXa5bp4A67S2UJRl1JiaWr0iaA/AUNI6cu0rGO+cO19/Vu0TRqEXfj4J /R+p17Ops6n7g6b0myhMJEA1w+ulbR582pSEB1lO0WocUR6dqGnM3hakhcYsTEEV cDYa/9v4pSwgk2qRmSleV0krwFEu+Bu0CvMH84IvHXIOekuhodHT65yGodSKQYEG 3M6z4YHKnLmARsEqCg/Q/5CEmJmBZRO2vQ+oeJDyqyYyzrJ4YBhQq//Io2SAm+mb 7zL7IzNo6+25hKGJfJglIsJa/XVhmR3YUbzX+HAj7m0sRfumSM8HSOaAH4rK/oDL KKfx1WVuLv3f1PG427i/0LTxOB3hRPpcTEQRyM0iFN0AcmFDN+SlPK/1MWjp5Maq V9pqurXG1/Zknk4pGFBanu/kFY9KVrUvH+WB4WfLoYqd3dX5fYlYf51NKExs+tda GQSQlRYMdhjtF5l9TmckeACLiyxZY/NfvHfOsD7Ze+kMFhXZLrySDnlxUPE1K+CX 0AiGQW0mkbaSrVM1i/yvBlll48K0K8u0DH/+yqQB/a4HlB/n/FrrZUfUheofHZbr C4b8MMMfUJnurF367xJ33ui1ve30lgvBajUg5/e2u+7UUQj89VT7Vsea/j1hicaK CpIhqgQYSmYGaSXSF5m/ =gP6r -----END PGP SIGNATURE----- --XltA7vj8ink7bXAnartuMF5uXP31wlIuB--