Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Eli Zaretskii <eliz@gnu.org> 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.

[-- Attachment #2: Type: text/html, Size: 3622 bytes --]