[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
From: |
Eli Zaretskii |
Subject: |
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. |
Date: |
Wed, 25 Nov 2015 21:24:23 +0200 |
> From: Philipp Stephani <address@hidden>
> Date: Wed, 25 Nov 2015 18:50:05 +0000
> Cc: address@hidden
>
> 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.