Re: Dynamic loading progress

[Aurélien Aptel]

The dynamic-modules-2 branch is implemented from scratch (well, from
the master branch) in case that wasn't clear.

I'll summarize what the code is doing, to make sure with everyone I'm
not doing anything wrong.

Emacs core has a new module.c[0] file which provides various function
pointers to modules via a struct (actually 2 struct, there's
emacs_environment and emacs_runtime). These structs are defined in
src/emacs_module.h [1].

A module has an emacs_module_init function which is called when the
module is loaded. This function is passed an emacs_environment pointer
which is used by the module to get a emacs_runtime pointer which has
all the useful function pointers to interact with emacs.

Lisp_Object are exposed via the emacs_value type which is opaque. From
emacs_module.h:

    typedef void* emacs_value;

To convert a Lisp_Objet to an emacs_value I simply cast, currently.
>From Emacs' module.c:

    static emacs_value module_make_fixnum (emacs_env *env, int64_t n)
    {
      return (emacs_value) make_number (n);
    }

(let's just ignore the overflow and error checking for now and focus
on the architecture)

Daniel's last message made me understand the GC problem. Since emacs
integers are stored directly "in" the Lisp_Object there's no problem
with the GC because there's no memory to free. But for other more
complex types (where the Lisp_Object is actually a pointer) an
emacs_value stored by the module can become invalid between 2
emacs->module calls because it was garbage collected.

So what I should do is make another Lisp_Object-like union type that
owns its memory (ie. not handled by the GC) and use that as
emacs_value (still opaque for the module). Correct?

0: 
https://github.com/aaptel/emacs-dynamic-module/blob/dynamic-modules-2/src/module.c
1: 
https://github.com/aaptel/emacs-dynamic-module/blob/dynamic-modules-2/src/emacs_module.h