[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Philipp Stephani
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Wed, 25 Nov 2015 18:50:05 +0000

Eli Zaretskii <address@hidden> 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

  . 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).
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]