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: emacs-module.c and signaling errors Date: Thu, 26 Nov 2015 17:42:02 +0200 Message-ID: <83vb8ovkc5.fsf@gnu.org> References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com> <83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu> <87si3vox7j.fsf@tromey.com> <56555B52.3030703@cs.ucla.edu> <837fl6xa02.fsf@gnu.org> <5655F10D.9080805@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448552554 9285 80.91.229.3 (26 Nov 2015 15:42:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 15:42:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 26 16:42:24 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 1a1ygi-0006Br-4q for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 16:42:24 +0100 Original-Received: from localhost ([::1]:51826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ygk-0000EY-Db for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 10:42:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ygg-0000De-U1 for emacs-devel@gnu.org; Thu, 26 Nov 2015 10:42:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1ygd-00071b-NK for emacs-devel@gnu.org; Thu, 26 Nov 2015 10:42:22 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:49827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1ygd-00071S-AA for emacs-devel@gnu.org; Thu, 26 Nov 2015 10:42:19 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NYF00O00HQGWD00@mtaout24.012.net.il> for emacs-devel@gnu.org; Thu, 26 Nov 2015 17:35:06 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYF00FKKHYINY90@mtaout24.012.net.il>; Thu, 26 Nov 2015 17:35:06 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:195288 Archived-At: > From: Stefan Monnier > Date: Wed, 25 Nov 2015 16:23:24 -0500 > > > I think Daniel is worried that module code will call xmalloc, and then do > > more work that signals an Elisp error or throws a C++ exception, and the > > module will then leak the xmalloced memory. There may be other concerns like > > that too, but I'm not sure what they are. > > I find it hard to believe that we'd follow Daniel's recommendation > over mine. As far as I know, he didn't give any more evidence of his > assertions of goodness of his approach than I did (OTOH, it's obvious at > the technical level that Daniel's approach can be layered on top of > mine, whereas the reverse is not true, which I think should a strong > argument in favor of following the simpler approach I advocate). Are you talking about signaling and throwing in case of errors? Or are you talking about something else? I think we should be pragmatic here. If there's a way of having an interface that is safe in the face of the likes of C++ exceptions, without unduly punishing module authors, we should take it. It sounds like a win-win to me. I believe we've already found a reasonably good way to handle signaling errors and throwing. (I will soon install the changes I posted yesterday.) With that in place, module code that wants to signal an error will look very much like what we do in core in similar situations. Paul wants to extend these conveniences to memory allocation, and that is what he wrote about above. I agree it would be nice to have that. I'm not sure I fully understand the concerns (Paul says he doesn't understand them fully, either), but with my perhaps limited understanding, I fail to see why the same approach -- save the information about the Lisp error in the environment object, then return instead of jumping, and let module-call signal -- cannot be used to provide a convenient memory allocator very similar to xmalloc. At worst, we will just need to teach emacs-module.c about the "memory-full" error, that's all. Am I missing something?