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 15:28:03 -0800 Organization: UCLA Computer Science Department Message-ID: <5679DC83.70405@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> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.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 1450826908 22571 80.91.229.3 (22 Dec 2015 23:28:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 23:28:28 +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 Wed Dec 23 00:28:18 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 1aBWLp-0006Ww-6k for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 00:28:17 +0100 Original-Received: from localhost ([::1]:53402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBWLo-0001lR-Bq for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 18:28:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBWLj-0001l4-P6 for emacs-devel@gnu.org; Tue, 22 Dec 2015 18:28:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBWLi-0006pp-RF for emacs-devel@gnu.org; Tue, 22 Dec 2015 18:28:11 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBWLe-0006mf-52; Tue, 22 Dec 2015 18:28:06 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C62071601D5; Tue, 22 Dec 2015 15:28:04 -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 fn69RX9tyzEe; Tue, 22 Dec 2015 15:28:04 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0AB4C160D1A; Tue, 22 Dec 2015 15:28:04 -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 uX9A-Seo0ODg; Tue, 22 Dec 2015 15:28:03 -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 CF8B41601D5; Tue, 22 Dec 2015 15:28:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <8337uuqsux.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:196694 Archived-At: Eli Zaretskii wrote: > Is that practical? One problem that I, as a module developer would > face, is to estimate the amount of stack I'd need for unwinding. > Where do I begin? We could merely require that any module needing recursion must call a new stack-size-checking function at each level of recursion, in order to detect stack overflow. Also, any module with an unbounded amount of computation should call the equivalent of QUIT every now and then. If the module API doesn't let (or ideally, require) modules to do that now, it should. Otherwise it's an Emacs freeze waiting to happen. > Then there are all the stack frames below the module, which belong to > some Lisp someone else wrote -- who will be responsible for ensuring > those other unwinders don't need large amounts of stack space that > might be unavailable at stack-overflow point? Each stack-overflow unwinder should use only a small amount of stack space, in order to prevent an infinite loop. We could partially enforce this by detecting trivial infinite stack-overflow loops. > Stack overflow detection on modern systems uses hardware assistance > and processor exceptions to detect overflow with no runtime > penalties. Doing the equivalent in application code is bound to incur > additional processing, which will slow down code, right? Yes, but it's not a big deal. > If you think > about manipulating the guard pages to make them resizable, are we sure > enough of the supported platforms allow that? In platforms that don't support guard pages we'll need to have the run-time checks. Either approach should be adequate. > Hitting stack overflow when some module runs is even rarer. > Why is it a disaster to fail to invoke the unwinders in those cases? Often I expect it wouldn't be a disaster; it'd just be a memory leak. I suppose there could be some modules where it would be a disaster. But perhaps we can just ask people to not write such modules, by making it a part of the Emacs API that unwinders might not be invoked.