Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Philipp Stephani]

Philipp Stephani <address@hidden> schrieb am Sa., 19. Dez. 2015 um 22:03 Uhr:

Philipp Stephani <address@hidden> schrieb am Sa., 28. Nov. 2015 um 11:58 Uhr:

Philipp Stephani <address@hidden> schrieb am Fr., 27. Nov. 2015 um 20:19 Uhr:

Eli Zaretskii <address@hidden> schrieb am Fr., 27. Nov. 2015 um 08:36 Uhr:

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Thu, 26 Nov 2015 13:29:49 -0800
>
> Eli Zaretskii wrote:
> > it would be a maintenance burden to have to
> >      analyze upon each such change whether emacs-module.c needs some
> >      augmentation.
>
> While that's true in general, I think some exceptions are OK.  E.g., it's OK if
> emacs-module.c assumes that ASIZE is a simple access function or macro that
> doesn't throw signals.  If we actually changed ASIZE to throw signals, there's a
> boatload of other code we'd need to change as well, and changing emacs-module.c
> wouldn't add much more to the maintenance burden.

So what are the rules here, exactly?  I'd like to write them down in
the commentary to emacs-module.c, so that any future changes there
will have lower probability of breaking things.

E.g., can make_number signal an error?  What about make_float or
make_string?  And what about accessors like XFLOAT_DATA or AREF?

Are there any established rules? If not we should probably be conservative and  assume that everything signals. If we figure out that this introduces an unacceptably high overhead in some situations we can reconsider later.

I would propose three exceptions: free_global_ref, is_not_nil, eq. free_global_ref cannot fail in Daniel's design, and implementing it that way would be consistent with other resource deallocation functions such as free(3). is_not_nil and eq seem so fundamental that I cannot imagine a situation where they could ever fail. Documenting that these three cannot fail would free module authors from the need to check for errors after calling these functions.

For now I've attached a patch to replace the initial setup of most environment functions with a single macro. 

Here's another patch that replaces some of the custom error handling with signals. The signals will be immediately caught by the prologue, but some complexity and duplication is removed. 

Added another patch that documents some of the assumptions about non-local exits. I've added them directly to lisp.h so that people changing these definitions will hopefully notice. 

0001-Document-assumptions-about-non-local-exits.patch
Description: Binary data