Re: Dynamic loading progress

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

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

Paul Eggert <eggert@cs.ucla.edu> schrieb am Do., 19. Nov. 2015 um 16:55 Uhr:

> The main thing I noticed (that was not already in your list or in my
> upcoming changes) are some problems in memory allocation. The module
> code calls malloc directly, instead of xmalloc, for reasons I don't
> understand. This leads to problems, e.g., the memory is not properly
> accounted for by the memory profiler. Why can't the new module code
> invoke xmalloc? More generally, how should modules obtain memory in an
> Emacs-friendly way?
>

The problem with xmalloc is that it can signal (i.e. call longjmp). Modules
are generally not prepared for long jumps, so it's important that no
longjmp escapes into module code. The easiest way to ensure this is to make
code not call longjmp in the first place.
Some of the code in module.c does call longjmp; that is protected by
appropriate calls to setjmp. We could do that with all code, but for cases
like malloc it seemed simple enough to avoid the calls to longjmp
altogether.
Maybe we should add a variant that behaves like xmalloc but is guaranteed
to never call longjmp?


>
> Also, the file name "emacs_module.h" doesn't use the usual Emacs style
> rules; hyphen not underscore.


If a hyphen is preferred, feel free to rename.


> But as you say, "module.h" would be better
> anyway. I'll change it to "module.h" for now; if there's some reason it
> needs an "emacs" prefix we can change it to "emacs-module.h" later.
>
>
Please don't use module.h; this header file is the only one that is
intended for module authors to include, so it needs a globally unique name
which should start with 'emacs'.


> There are some other things I noticed which I'll try to summarize after
> fixing the stuff that's easy to fix (missing copyright notices,
> formatting, etc.).
>
>

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