Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

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

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

Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 27. Nov. 2015 um 08:36 Uhr:

> > Cc: emacs-devel@gnu.org
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > 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.

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