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 23:08:33 +0200 Message-ID: <83twnap4xa.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> <83oadiqxq1.fsf@gnu.org> <5679B33E.9000804@dancol.org> <83y4cmp5y5.fsf@gnu.org> <5679B7F5.9030504@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450818491 10656 80.91.229.3 (22 Dec 2015 21:08:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Dec 2015 21:08:11 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, eggert@cs.ucla.edu, tzz@lifelogs.com, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 22 22:08:07 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 1aBUAB-0000Aw-Gh for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 22:08:07 +0100 Original-Received: from localhost ([::1]:52991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUAA-0008Sk-UW for ged-emacs-devel@m.gmane.org; Tue, 22 Dec 2015 16:08:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUA6-0008SS-SQ for emacs-devel@gnu.org; Tue, 22 Dec 2015 16:08:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBUA3-0001JS-Lx for emacs-devel@gnu.org; Tue, 22 Dec 2015 16:08:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBUA3-0001JO-Ii; Tue, 22 Dec 2015 16:07:59 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1838 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBUA2-0006Ei-LL; Tue, 22 Dec 2015 16:07:59 -0500 In-reply-to: <5679B7F5.9030504@dancol.org> (message from Daniel Colascione on Tue, 22 Dec 2015 12:52:05 -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:196692 Archived-At: > Cc: eggert@cs.ucla.edu, aurelien.aptel+emacs@gmail.com, > p.stephani2@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 22 Dec 2015 12:52:05 -0800 > > > If you only longjmp a short while, you have no idea how much stack you > > freed. You might as well be just 200 bytes below the level where the > > stack overflow hit. > > Which is why you setjmp in places where you have a significant stack > reserve. There's no way of doing that portably, or even non-portably on many platforms. You simply don't _know_ how much stack is left. > > No, the core isn't in a bad state. Longjmp is not an abnormal path, > > its semantics is very simple and clear. > > Longjmp, by itself, is simple and clear. What's unreliable is longjmping > to Lisp at completely arbitrary points in the program, even ones marked > "GC can't happen here" and the like. We longjmp to a particular place, not arbitrary place. > You say Emacs shouldn't crash. Fine. We can't make that guarantee > if the crash recovery code breaks program invariants. Crash recovery doesn't need to keep invariants. Or maybe I misunderstand what invariants do you have in mind. > If you want to longjmp, you need to do it at certain well-defined > points only. The current approach is a bug machine. No, it isn't. There's a small number of places (2?) to which we jump. That's all. > >> We can gracefully recover from stack overflow of Lisp code. We > >> cannot recover from stack oveflow at arbitrary points in the C core. > > > > We can and we do. The recovery has only to be good enough to allow > > saving your work and exiting. That's the only goal of that > > protection: allow the user to exit normally, after saving their work. > > I'd rather rely on autosaves. It's not reliable enough, because it happens relatively rarely. Doing it much more frequently will be an annoyance with many buffers. And then there are buffers that don't autosave, but the user might still want to do something with them if she needs to abandon ship. > Failing that, we should allocate guard pages, unprotect the guard > pages on overflow Thats what the OS is for. It would be wrong for us to start messing with page protection etc. The exception caused by stack overflow removes protection from the guard page to let you do something simple, like run the exception handler -- are you suggesting we catch the exception and mess with protection bits as well, i.e. replace one of the core functions of a modern OS? All that because what we have now is not elegant enough for us? Doesn't sound right to me. > and call out_of_memory so that it's obvious Emacs is in a bad > state. This way, we don't have to longjmp out of arbitrary code > sequences. There's no problem longjmping out of arbitrary code sequences. When you debug a program, you do that all the time.