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 17:46:20 +0200 Message-ID: <83io3rst2r.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1450712787 11397 80.91.229.3 (21 Dec 2015 15:46:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 15:46:27 +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 16:46:18 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 1aB2fC-0002CC-69 for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 16:46:18 +0100 Original-Received: from localhost ([::1]:45700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB2fB-0003p4-Gl for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 10:46:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB2ep-0003oV-7j for emacs-devel@gnu.org; Mon, 21 Dec 2015 10:45:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aB2em-0001DC-0v for emacs-devel@gnu.org; Mon, 21 Dec 2015 10:45:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aB2el-0001D8-M2; Mon, 21 Dec 2015 10:45:51 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4933 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aB2ej-0001b9-63; Mon, 21 Dec 2015 10:45:51 -0500 In-reply-to: <5677DBC9.6030307@cs.ucla.edu> (message from Paul Eggert on Mon, 21 Dec 2015 03:00:25 -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:196604 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 03:00:25 -0800 > > Then we either cannot use them in emacs-module.c, > > The lisp.h functions are no different from any other functions in this respect, so this is not a lisp.h problem. Stack overflow can occur with any function call, even functions defined within emacs-module.c itself. This discussion started so long ago that we've lost the perspective, and its main point is no longer in our sights. Let me remind that. A long time ago in a galaxy far, far away, I wrote in http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg02190.html: > > . Why don't some functions use any of these macros, although they do > > call Emacs functions? Examples include module_make_integer (calls > > make_number), and module_make_user_ptr (calls make_user_ptr). > > > > . It seems like emacs-module.c assumes something about certain Emacs > > functions, and based on that decides not to use these macros even > > when calling those Emacs functions. For example, module_vec_get > > calls ASIZE and AREF, but doesn't use the MODULE_HANDLE_* macros. > > Evidently, it assumes that neither ASIZE nor AREF will ever signal > > or throw. But isn't that a fragile assumption? The > > implementation of internal Emacs functions is subject to change > > without notice, and it would be a maintenance burden to have to > > analyze upon each such change whether emacs-module.c needs some > > augmentation. And you replied in http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg02270.html: > While that's true in general, I think some exceptions are OK. E.g., it's OK if emacs-module.c assumes that ASIZE is a simple access function or macro that doesn't throw signals. If we actually changed ASIZE to throw signals, there's a boatload of other code we'd need to change as well, and changing emacs-module.c wouldn't add much more to the maintenance burden. Phillip's comments that you reverted were the logical consequence of the apparent conclusion we drew from the above exchange: that it was okay to assume these functions/macros cannot throw signals. 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? 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. > If emacs-module.c is incompatible with stack overflow detection, then we should put a FIXME comment in emacs-module.c saying so, as this is a recently-introduced bug that should get fixed. I did this just now. > Perhaps someone with C++ expertise can chime in and say how C++ programs are expected to deal with stack overflow. Whatever mechanism is used, Emacs should be using it. I have no idea how (or even if) C++ code can cope with stack overflow, except by leaking all the objects that were alive at the point where we detected stack overflow. 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. > Come to think of it, there must be a better way for emacs-module.c to deal with C++ exceptions. The current approach is complex, confusing and error-prone. If emacs-module.c or the Emacs exception-handling mechanism really needs to be rewritten in C++ in order to catch C++ exceptions nicely, then somebody with C++ expertise should do that. (Optionally, of course; it should be OK to have a C-only Emacs that does not worry about C++ modules.) If done well, that should simplify the module interface considerably, for both C and C++. 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, until we return back to the Lisp interpreter that called the module function. But it will not cause any C++-specific trouble. 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?