Re: Dynamic loading progress

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

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

Daniel Colascione <dancol@dancol.org> schrieb am So., 4. Okt. 2015 um
21:34 Uhr:

> On 10/04/2015 02:41 AM, Philipp Stephani wrote:
> >     >
> >     >
> >     >       typedef struct emacs_value_tag* emacs_value;
> >     >
> >     >
> >     > I think it's important that this is a pointer to a struct (for type
> >     > safety and size correctness) rather than just an arbitrary type.
> >
> >     A typedef is exactly as typesafe. The question of whether to use a
> >     struct or a typedef is aesthetic. I strongly prefer a typedef, just
> like
> >     pthreads, and I believe that the people who advocate using structs
> >     directly are simply wrong.
> >
> >
> > Ah, I'm not against the typedef, I'm just asking whether you would make
> > it part of the API contract that it's a typedef of a struct pointer, or
> > whether it can be any type.
>
> The problem with defining it as a pointer type is that NULL is now the
> invalid sentinel value, which seems incompatible with both making this
> thing literally a Lisp_Object and Qnil having all zero bits.
>
> That's why I strongly prefer making emacs_value a _pointer_ to a
> Lisp_Object, where we store the Lisp_Object in an array owned by the
> emacs_env. This way, allocating local values is very cheap.
>

A simple fixed array however puts a fixed upper bound on the number of
local values used. That might be undesirable, especially for plugins
dealing with large data structures. The simplest unbound allocation
mechanism would use an array of emacs_value pointers (emacs_value **)
stored in the environment object; the array itself and its elements would
be allocated using malloc as usual, and the array would be grown using
realloc. However, that requires lots of allocations (at least one per local
object used) and could make a more complex allocator necessary.

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