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: Tue, 22 Dec 2015 08:39:53 -0800 Organization: UCLA Computer Science Department Message-ID: <56797CD9.8010706@cs.ucla.edu> References: <83mvu1x6t3.fsf@gnu.org> <565779CD.80405@cs.ucla.edu> <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> 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 1450802421 8367 80.91.229.3 (22 Dec 2015 16:40:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 16:40:21 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org, tzz@lifelogs.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 17:40:12 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 1aBPyt-0005Rq-Rm for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 17:40:11 +0100 Original-Received: from localhost ([::1]:51544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPyt-0000Gu-7L for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 11:40:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPyo-0000FD-MT for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:40:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBPyl-00052x-RJ for emacs-devel@gnu.org; Tue, 22 Dec 2015 11:40:06 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBPyg-0004r4-UK; Tue, 22 Dec 2015 11:39:59 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 170DA16066A; Tue, 22 Dec 2015 08:39:58 -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 1DjqwM-otNRQ; Tue, 22 Dec 2015 08:39:57 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 579DF160D3D; Tue, 22 Dec 2015 08:39:57 -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 kbT5Onuef4gQ; Tue, 22 Dec 2015 08:39:57 -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 2C58E16066A; Tue, 22 Dec 2015 08:39:57 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83mvt2qxm1.fsf@gnu.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:196675 Archived-At: Eli Zaretskii wrote: >> The only real change we have to make is to have Emacs longjmp not to >> > return_to_command_loop (which might skip module frames), but to longjmp >> > instead to the most deeply nested entry point from module code into >> > Emacs, which we can set up in advance whenever a module calls into the >> > Emacs API. >> > >> >Yes, that looks like something we should do, then, to get stack overflow checking working with modules. > If that means letting modules run arbitrary stack unwinding code on > the alternate stack, I'm against that. Likewise. My thought was more to require that the module code's most deeply nested frame must be on the main stack, with some (perhaps configurable) amount of unused stack space above it, so that any module-specific unwinding would be done on the main stack. In other words, the module code knows about stack overflow and has methods (either a runtime check on each call as Daniel suggests, or guard pages and constraints about module stack frame sizes if this works and has better performance) to detect it. We might also want to put in something to catch trivial stack-overflow infinite loops, if they turn into an issue. This would give up on catching a looping stack-overflow and would go back to the previous catch. This would break destructor-based invariants, but that's often better than crashing. It's akin to the existing 3x C-g signal, which breaks invariants all over the place (including invariants in module code!) but in my experience is crucial.