From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Mon, 21 Dec 2015 03:00:25 -0800 Organization: UCLA Computer Science Department Message-ID: <5677DBC9.6030307@cs.ucla.edu> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1450695666 22892 80.91.229.3 (21 Dec 2015 11:01:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Dec 2015 11:01:06 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org, tzz@lifelogs.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 21 12:00:57 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 1aAyD2-0003Xj-5g for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 12:00:56 +0100 Original-Received: from localhost ([::1]:44017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAyD1-0003qC-Nm for ged-emacs-devel@m.gmane.org; Mon, 21 Dec 2015 06:00:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAyCi-0003pz-TS for emacs-devel@gnu.org; Mon, 21 Dec 2015 06:00:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAyCh-0004sI-KD for emacs-devel@gnu.org; Mon, 21 Dec 2015 06:00:36 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAyCZ-0004nl-W2; Mon, 21 Dec 2015 06:00:28 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1F4FD1607C4; Mon, 21 Dec 2015 03:00:27 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ksFMLsL2-HlX; Mon, 21 Dec 2015 03:00:26 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5176A160D24; Mon, 21 Dec 2015 03:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r31i9hMkyryw; Mon, 21 Dec 2015 03:00:26 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 245271607C4; Mon, 21 Dec 2015 03:00:26 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <83zix4scgf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:196597 Archived-At: Eli Zaretskii wrote: > 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. > or should place > comments there to the effect that we disregard that possibility (and > maybe augment the comments in lisp.h saying that stack overflow is the > only allowed reason for non-local exits). Which one do we prefer? 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. 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++. If this simplification cannot be done, one possible workaround would be to say that C++ modules should not use nontrivial destructors. This would be a different way to let us simplify emacs-module.c significantly, albeit a way that is less satisfactory for C++ modules.