Re: [Pika-dev] Guile FFI: resizable vector problem

[Matthew Dempsky]

address@hidden writes:

> realloc cannot be used because, as I mentioned previously, to support
> the interleaving semantics, you may need both the vector before and
> the vector after simultaneously.  I would suggest to model it slightly
> differently:

[...]

I think you're misunderstanding the abstraction barrier we're using in
Pika - let me try to explain again what's going on first.

Pika supports vtable objects with slots (fixed immediate t_scm_word
values) and limbs (resizable arrays of t_scm_word values).  At
present, the only support for getting access to either of these is
through interfaces like (from reps/vtable-obj-imp.h):

extern void scm_ref_slot (t_scm_word * result,
                          t_scm_arena arena,
                          t_scm_word * value,
                          t_uint slot);
extern void scm_set_slot (t_scm_arena arena,
                          t_scm_word * obj,
                          t_uint slot,
                          t_scm_word * value);
extern void scm_ref_limb_elt (t_scm_word * result,
                              t_scm_arena arena,
                              t_scm_word * value,
                              t_uint limb,
                              t_uint offset);
extern void scm_set_limb_elt (t_scm_arena arena,
                              t_scm_word * obj,
                              t_uint limb,
                              t_uint offset,
                              t_scm_word * value);

Vectors are basically a vtable object type along with a bit of wrapper
code around those limb procedures so all of the issues of locking and
memory layout, etc. are hidden behind the abstraction barrier of the
code in reps (i.e. the client code never holds a reference to a
t_scm_word in the heap).

In the big picture of Pika as a whole, there's no worries about
locking yet because the only interfaces provided are expected to
operate atomically in the face of multithreaded applications (assuming
the reps implementation supports multithreading).  You can basically
think of this interface as the safe-no-worries-but-possibly-too-slow
interface that general users are expected to use when they don't have
any critical code to use.  (The issue of a crap-we-need-speed
interface that allows direct, locked access to the limbs will come
later.)

However, what we've been talking about regarding Guile specifically is
reusing Guile's vector type to implement the limbs part of a vtable
object.  While locking in the scm_limbs functions would probably be
needed to properly support multithreaded applications, it's not an
issue that leaks beyond the interface (yet) so it can be solved
entirely in the Guile-as-reps code possibly using the idiom you
recommended -- either way, it's not an issue that requires code
outside of the reps/ directory to be changed (which is rather
minimal).

-jivera