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:46:17 +0200 Message-ID: <83egedp0yu.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> <83oadhp2mj.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450889164 30452 80.91.229.3 (23 Dec 2015 16:46:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 16:46:04 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 23 17:46:03 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 1aBmY5-00050a-QN for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 17:46:02 +0100 Original-Received: from localhost ([::1]:56877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmY4-00057C-K4 for ged-emacs-devel@m.gmane.org; Wed, 23 Dec 2015 11:46:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmXq-00056u-UN for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:45:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBmXm-0000Tg-CL for emacs-devel@gnu.org; Wed, 23 Dec 2015 11:45:46 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBmXm-0000TZ-8c; Wed, 23 Dec 2015 11:45:42 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2275 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aBmXl-0004td-4S; Wed, 23 Dec 2015 11:45:41 -0500 In-reply-to: (message from Philipp Stephani on Wed, 23 Dec 2015 16:20:45 +0000) 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:196718 Archived-At: > From: Philipp Stephani > Date: Wed, 23 Dec 2015 16:20:45 +0000 > Cc: aurelien.aptel+emacs@gmail.com, dancol@dancol.org, tzz@lifelogs.com, > emacs-devel@gnu.org > > > 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.) > > There's no harm in providing such a functionality (but of course we can't > enforce its use). We will document that in the manual and comment on non-complying code. > Alternatively modules can run computations in background > threads and update Emacs state in timer functions. I'd be very weary of going that way. Emacs's design doesn't support such techniques very well, and they will of course multiply complexity. > 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. > > The disaster is that longjmps cause undefined behavior in C++ if destructors > would be skipped (and I don't even want to imagine what would happen to > higher-level languages such as Java or Haskell). It is not a disaster if the user saves and exits right after the recovery, instead of continuing to use the session that hit stack overflow. Nothing bad will happen. > 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. > > handle_sigsegv already has several cases where the longjmp is skipped: when in > a GC, when the signal is received from the wrong thread, and when it's not > guaranteed to be a SO. In those cases Emacs aborts (still autosaving). Why > can't we do the same if SO is detected while a module function is active? It won't auto-save in those cases, and if we try, we will most probably crash anyway. Those cases are when we have no better alternative, and if someone comes up with an idea for solving some of them, we will definitely consider it. Making stack overflow do the same is a step backward, because it will increase the probability of losing work.