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: Mon, 21 Dec 2015 20:57:47 +0200 Message-ID: <83zix3r5n8.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450724260 7449 80.91.229.3 (21 Dec 2015 18:57:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 18:57:40 +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 Mon Dec 21 19:57:35 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 1aB5eJ-0004Rp-2B for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 19:57:35 +0100 Original-Received: from localhost ([::1]:46858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5eI-0004Ek-AD for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 13:57:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5e5-0004EY-FM for emacs-devel@gnu.org; Mon, 21 Dec 2015 13:57:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aB5e2-00016H-1r for emacs-devel@gnu.org; Mon, 21 Dec 2015 13:57:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB5e1-00016D-VH; Mon, 21 Dec 2015 13:57:17 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1324 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aB5e1-00050R-0k; Mon, 21 Dec 2015 13:57:17 -0500 In-reply-to: <567841A6.4090408@cs.ucla.edu> (message from Paul Eggert on Mon, 21 Dec 2015 10:15:02 -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:196623 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: Mon, 21 Dec 2015 10:15:02 -0800 > > Eli Zaretskii wrote: > > > Are you > > now saying something different from what you said back then, i.e. that > > we cannot rely on any function/macro from lisp.h to be signal-safe? > > Yes and no. As I understood it, that old conversation was about functions that > explicitly signal or throw, and it's safe to assume that EQ, NILP, etc. won't do > that. The new conversation is about running out of memory, which is a different > form of non-local exit. There may be other forms, such as operating-system > signals (I don't recall exactly). The old and the new conversations are about the same: non-local exits in functions defined by lisp.h and other Emacs sources. > > If so, we should add the necessary protection, in the form of calls to > > MODULE_FUNCTION_BEGIN, to emacs-module.c functions that until now > > relied on those lisp.h functions/macros to be safe. > > This wouldn't suffice for these other non-local exits, I think; at least, not as > currently constructed. So the comments you deleted were correct: emacs-module.c can and does rely on those functions and macros not to signal or throw. > > AFAIK, proper C++ exception handling > > requires non-trivial amounts of stack space that is not available when > > there's stack overflow, where you have at most a single guard page to > > work with. > > There should be workarounds for that. Surely the C++ community has run into this > problem and has solutions. If we want to support C++ modules, we need to employ > them. I will have an opinion about that when I see such a solution. I'm not sure it exists. It's a rare C program that can recover from stack overflow; it wouldn't be a huge surprise to learn that no C++ program can do that portably, or at all. > > I think there is some misunderstanding here, or some confusion, > > perhaps mine: emacs-module.c is not supposed to deal with any C++ > > exceptions. C++ exceptions are supposed to be caught at the C++ > > level, below emacs-module.c, and handled there. An exception that > > isn't caught will be recorded and will cause all the subsequent calls > > to Lisp or to emacs-module.c function to fail, > > Why bother? If C++ exceptions are supposed to be caught by the C++ module in > question, why does Emacs need to worry about C++ exceptions that are not caught? It doesn't. I tried to explain that. It worries about longjmp etc. called by Lisp or by implementations of Lisp primitives provided by modules. > > What emacs-module.c does with non-local exits of _any_ kind is record > > the first occurrence of such an exit, and silently return to the > > caller, thus allowing the C++ objects on the stack to be destroyed > > normally. IOW, it defers the exit until internal--module-call is > > about to return. What problems do you see with that which cause you > > to think it's error-prone, let alone dysfunctional? > > It uses a different model at the C level from what one sees in Elisp, or from > what one normally sees in C for that matter. So what? It's so simple that I'm surprised we waste so much time discussing it. > I don't feel that I will really understand the model unless I see > some actual modules that do function calls and exception handling There's a test in mod-test that does that, you can look at it and trace in the debugger what happens in emacs-module.c once the error is signaled. > but it's hard to believe that a model that does silent > returns and that defers returns until later and that records some returns but > not others will be problem-free. Why is it hard? It records the info if the slot is vacant, so only the first instance gets recorded. All the subsequent calls see that the slot is not vacant and simply return without doing anything. How complicated is that? > Wouldn't it be simpler to have a module invoke analogs of > 'condition-case' and/or 'catch', and to dispense with the > funcall_exit stuff? No, not necessarily. Both are simple.