From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Wed, 25 Nov 2015 18:50:05 +0000 Message-ID: References: <83mvu1x6t3.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11442338c56de2052561ed8a X-Trace: ger.gmane.org 1448477426 7039 80.91.229.3 (25 Nov 2015 18:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 18:50:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , dancol@dancol.org, tzz@lifelogs.com, aurelien.aptel+emacs@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 19:50:23 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 1a1f94-0007wB-BY for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 19:50:22 +0100 Original-Received: from localhost ([::1]:47183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1f96-0005pP-7u for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2015 13:50:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1f91-0005pI-DU for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:50:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1f8z-0007Xr-TK for emacs-devel@gnu.org; Wed, 25 Nov 2015 13:50:19 -0500 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:37796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1f8x-0007Vy-Iy; Wed, 25 Nov 2015 13:50:15 -0500 Original-Received: by wmww144 with SMTP id w144so81449917wmw.0; Wed, 25 Nov 2015 10:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=I4ZZ6YZIuhPQbUoAz68CnF8xOWN5CmbTtlXYJdJ27hk=; b=0ilZk+n3rYa9BYChINYNEDJo3HT1gTr1QKHnahrEsq49tEFQmBBBwY2rR43wufweLu aMlyjroKOjNPD53DyqU8cCyKfsDqdrTvCeqq9wDIPcLGeLqPJ/Rh/q2JQnuvxxNsLI83 smSRcmRx4TBLa+TGZyldygzzWUnKCeCe22ivkb4H3vddiHkH/VjaS2NwNE/mAZ4EZLIQ 2Z3Nyb2e1sRKjvpnhizrygVYhlwRj+5mOQaB6rsmZJBXgdiDj5B4D4fzWyNPf1ambjvT Nc1GEmqG3oD0hjE6TMmL+kEVfVkp6upKzYmNvLkY7Aak9WcqFl9NJ/blx3Iw/3yrP8ah UE7w== X-Received: by 10.28.134.199 with SMTP id i190mr6217886wmd.33.1448477414746; Wed, 25 Nov 2015 10:50:14 -0800 (PST) In-Reply-To: <83mvu1x6t3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22e 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:195242 Archived-At: --001a11442338c56de2052561ed8a Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Mi., 25. Nov. 2015 um 19:39 Uhr: > These macros need more extensive documentation wrt when each one is > needed and why. > > I tried to "reverse-engineer" that information from its current usage, > and my best hypothesis is that they should be used if a functions > calls some Emacs function that could potentially signal an error or > throw. For example, module_make_function calls list4, module_funcall > calls Ffuncall, module_copy_string_contents calls ENCODE_UTF_8, etc. > > Is that correct? > > If it is, then I have a few questions: > > . 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. > . How to decide whether to use MODULE_HANDLE_SIGNAL or > MODULE_HANDLE_THROW (or both)? Again, it looks like the current > code simply assumes specific knowledge about certain Emacs > functions, knowledge which again can become outdated a year or a > month or a day from now. > > So bottom line (again assuming my guesses above are correct), I'd > suggest to use these macros in all the emacs-module.c functions, Yes, your thinking is correct. I used these macros based on the current implementation. If this is too brittle, then these macros should indeed be added to all environment functions (i.e. those functions that gets directly called from module code). 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). > 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. --001a11442338c56de2052561ed8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mi., 25. Nov. 2015 um 19:39=C2=A0Uhr:
These macros need more extensive documentation wrt when each one is
needed and why.

I tried to "reverse-engineer" that information from its current u= sage,
and my best hypothesis is that they should be used if a functions
calls some Emacs function that could potentially signal an error or
throw.=C2=A0 For example, module_make_function calls list4, module_funcall<= br> calls Ffuncall, module_copy_string_contents calls ENCODE_UTF_8, etc.

Is that correct?

If it is, then I have a few questions:

=C2=A0 . Why don't some functions use any of these macros, although the= y do
=C2=A0 =C2=A0 call Emacs functions?=C2=A0 Examples include module_make_inte= ger (calls
=C2=A0 =C2=A0 make_number), and module_make_user_ptr (calls make_user_ptr).=

=C2=A0 . It seems like emacs-module.c assumes something about certain Emacs=
=C2=A0 =C2=A0 functions, and based on that decides not to use these macros = even
=C2=A0 =C2=A0 when calling those Emacs functions.=C2=A0 For example, module= _vec_get
=C2=A0 =C2=A0 calls ASIZE and AREF, but doesn't use the MODULE_HANDLE_*= macros.
=C2=A0 =C2=A0 Evidently, it assumes that neither ASIZE nor AREF will ever s= ignal
=C2=A0 =C2=A0 or throw.=C2=A0 But isn't that a fragile assumption?=C2= =A0 The
=C2=A0 =C2=A0 implementation of internal Emacs functions is subject to chan= ge
=C2=A0 =C2=A0 without notice, and it would be a maintenance burden to have = to
=C2=A0 =C2=A0 analyze upon each such change whether emacs-module.c needs so= me
=C2=A0 =C2=A0 augmentation.

=C2=A0 . How to decide whether to use MODULE_HANDLE_SIGNAL or
=C2=A0 =C2=A0 MODULE_HANDLE_THROW (or both)?=C2=A0 Again, it looks like the= current
=C2=A0 =C2=A0 code simply assumes specific knowledge about certain Emacs =C2=A0 =C2=A0 functions, knowledge which again can become outdated a year o= r a
=C2=A0 =C2=A0 month or a day from now.

So bottom line (again assuming my guesses above are correct), I'd
suggest to use these macros in all the emacs-module.c functions,

Yes, your thinking is correct. I used these macros ba= sed on the current implementation. If this is too brittle, then these macro= s should indeed be added to all environment functions (i.e. those functions= that gets directly called from module code).
I left them out pur= ely for performance reasons: these macros both call setjmp and possibly mal= loc, which can incur a significant penalty, especially for environment func= tions that are very small otherwise (e.g. eq or is_not_nil).
=C2= =A0
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 hassl= e. Existing wrapper functions are e.g. internal_condition_case in eval.c, b= ut you'd need one wrapper function for each signature, which quickly re= sults in excessive code duplication. Therefore I used the macros.
--001a11442338c56de2052561ed8a--