From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Wed, 23 Dec 2015 18:10:28 +0200 Message-ID: <83oadhp2mj.fsf@gnu.org> 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> <5679DC83.70405@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450887011 28140 80.91.229.3 (23 Dec 2015 16:10:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 16:10:11 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 23 17:10:06 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 1aBlzJ-0007Hz-9x for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 17:10:05 +0100 Original-Received: from localhost ([::1]:56719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBlzI-0002BE-KK for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 11:10:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBlzB-0002Ai-FL for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:10:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBlz7-0001nm-CE for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:09:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBlz7-0001ng-89; Wed, 23 Dec 2015 11:09:53 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2247 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBlz5-0002Ly-QL; Wed, 23 Dec 2015 11:09:52 -0500 In-reply-to: <5679DC83.70405@cs.ucla.edu> (message from Paul Eggert on Tue, 22 Dec 2015 15:28:03 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:196711 Archived-At: > Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org, > tzz@lifelogs.com, emacs-devel@gnu.org > From: Paul Eggert > Date: Tue, 22 Dec 2015 15:28:03 -0800 > > 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. That's performance penalty. I don't think we should incur that, on behalf of a problem that really should "never" happen. > 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. I agree, but I think it's unrelated to stack overflow. (Though I think we will need to have a module-specific version of QUIT, as long as we keep the constraint of not directly longjmping from module code.) > 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. I don't think it's practical to require that unwinders use "only a small amount of stack space". Verifying that is non-trivial even if you know how the particular internals work; it's downright impossible if you are a Lisp programmer with only a minimal knowledge of C and the Emacs C levels, or none at all. > 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. I disagree. Compilers' settings to allow run-time stack-smashing detection are off by default for a good reason. > 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. I didn't mean platforms that don't support guard pages. I meant platforms that do, but don't allow you to mess with them. For starters, you need to know the address of the page at the end of the stack, which is not trivial. Then you need to change its protection, which I'm not sure all platforms will let you do, certainly in future-proof manner. (Don't modern hardened system prevent messing with page protection bits?) > 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. I think if we adopt the view that the user should save and exit ASAP following recovery from stack overflow (similar to what we expect when we run out of memory), the probability of a "disaster" in this scenario becomes much lower, perhaps negligible. All in all, I think the current recovery is "good enough", and investing significant efforts into making it slightly better will waste resources that are better applied to more important problems.