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, 25 Nov 2015 21:24:23 +0200 Message-ID: <83h9k9x4pk.fsf@gnu.org> References: <83mvu1x6t3.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448479496 10332 80.91.229.3 (25 Nov 2015 19:24:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 19:24:56 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, 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 Nov 25 20:24:46 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 1a1fgK-0006G5-OF for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 20:24:44 +0100 Original-Received: from localhost ([::1]:47313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fgM-0007rp-ET for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 14:24:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fgI-0007rh-DC for emacs-devel@gnu.org; Wed, 25 Nov 2015 14:24:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1fgF-0000HE-AU for emacs-devel@gnu.org; Wed, 25 Nov 2015 14:24:42 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:38798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1fgF-0000H4-2J for emacs-devel@gnu.org; Wed, 25 Nov 2015 14:24:39 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NYD00A00XM7KM00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Wed, 25 Nov 2015 21:24:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYD00AQJXWTKP00@a-mtaout23.012.net.il>; Wed, 25 Nov 2015 21:24:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:195246 Archived-At: > From: Philipp Stephani > Date: Wed, 25 Nov 2015 18:50:05 +0000 > Cc: emacs-devel@gnu.org > > I left them out purely for performance reasons: these macros both call setjmp > and possibly malloc, which can incur a significant penalty, especially for > environment functions that are very small otherwise (e.g. eq or is_not_nil). Be that as it may, I really don't think we have any reasonable alternative. Anything else will be a bug waiting to happen. > and > in fact come up with a wrapper around calls to Emacs functions and > macros that will catch signals and throws, and make a point of calling > each such function/macro through that wrapper. > > My first approach was to create such a wrapper function, but I quickly realized > that it's too much of a hassle. Existing wrapper functions are e.g. > internal_condition_case in eval.c, but you'd need one wrapper function for each > signature, which quickly results in excessive code duplication. Therefore I > used the macros. Maybe we could come up with some clever macro wrappers instead. Macros are not really bound by function signature limitations, so maybe there is a way. Failing that, we will have to clearly document that use of these macros in every emacs-module.c function is mandatory. And maybe also have only one macro instead of 2, which catches both signals and throw's.