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: Tue, 22 Dec 2015 19:46:14 +0200 Message-ID: <8337uuqsux.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450806351 10907 80.91.229.3 (22 Dec 2015 17:45:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 17:45:51 +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 Tue Dec 22 18:45:50 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 1aBR0Q-0002ip-0P for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 18:45:50 +0100 Original-Received: from localhost ([::1]:52292 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBR0P-00010U-A6 for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 12:45:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBR0M-00010O-8q for emacs-devel@gnu.org; Tue, 22 Dec 2015 12:45:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBR0I-0006bY-5w for emacs-devel@gnu.org; Tue, 22 Dec 2015 12:45:46 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBR0I-0006bU-2N; Tue, 22 Dec 2015 12:45:42 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1609 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBR0H-0001jW-50; Tue, 22 Dec 2015 12:45:41 -0500 In-reply-to: <56797CD9.8010706@cs.ucla.edu> (message from Paul Eggert on Tue, 22 Dec 2015 08:39:53 -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:196679 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 08:39:53 -0800 > > 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. 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? 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? 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? If you think about manipulating the guard pages to make them resizable, are we sure enough of the supported platforms allow that? IOW, I simply don't see how this could be practical Stack overflow, like any other fatal error, are very infrequent events in Emacs. Hitting stack overflow when some module runs is even rarer. Why is it a disaster to fail to invoke the unwinders in those cases? My warm advice to users is to save and exit immediately after the recovery anyway, so I fail to see why some resource leak is a grave problem. Anyone who continues a session that recovered from stack overflow is playing with fire anyway.