From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Wed, 23 Dec 2015 18:51:23 -0800 Organization: UCLA Computer Science Department Message-ID: <567B5DAB.2000900@cs.ucla.edu> References: <83mvu1x6t3.fsf@gnu.org> <83io4nuc68.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1450925514 19602 80.91.229.3 (24 Dec 2015 02:51:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 02:51:54 +0000 (UTC) Cc: Emacs Development To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 24 03:51:45 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 1aBw0H-000443-2K for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 03:51:45 +0100 Original-Received: from localhost ([::1]:58646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBw0G-0004fl-3j for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 21:51:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBw02-0004fT-T3 for Emacs-devel@gnu.org; Wed, 23 Dec 2015 21:51:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBvzx-0001nq-TO for Emacs-devel@gnu.org; Wed, 23 Dec 2015 21:51:30 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBvzx-0001nF-Je for Emacs-devel@gnu.org; Wed, 23 Dec 2015 21:51:25 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9A4E9160D1A; Wed, 23 Dec 2015 18:51:24 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0RzNIaaoYGlz; Wed, 23 Dec 2015 18:51:23 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D987F160D25; Wed, 23 Dec 2015 18:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F9KhlSkULL-Z; Wed, 23 Dec 2015 18:51:23 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BBEC1160D1A; Wed, 23 Dec 2015 18:51:23 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <567AD766.3060608@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:196746 Archived-At: Daniel Colascione wrote: > Python uses explicit runtime checks, IIRC. HotSpot uses a guard page. This suggests that Emacs could profitably use either approach to detecting stack overflow. >> We *could* enforce the use by requiring at least one call to QUIT every >> (say) 100 ms, and by doing the equivalent of 3x C-g when the time limit >> is exceeded. That'd be useful even without modules. > > That's grossly unacceptable. Individual page faults (over which programs > have little control) can take longer than that. 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. > Besides, modifying all code to fit into Emacs' idiosyncratic model of > stack overflow detection is unreasonable. There should be no need to modify library code. We should be able to get this to work by having the library wrapper deal with the issue one way or another. > Please stop repeating the false idea that > longjmp from arbitrary points in the program to toplevel is harmless. 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 functionality. > the current mechanism does not achieve its goal. It's > utterly unsafe even without module code added to the mix. It's safe enough in practice. You're right that in *theory* it's utterly unsafe, but Emacs is a practical program not a theoretical exercise. 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.