[CM] Idea: using handles instead of pointers, s7_clone

[Christos Vagias]

Thank you both for your responses and insight!

I was thinking of trying to make this change myself, but after your
comments perhaps I'll not. It's still something though that in the
long term I'd like to try (given plenty of free time!)

The discussion could end now, but in case you're interested I'd like
to clarify some things.

To Elijah: I didn't get your comment of "limit the heap to 1b objects".
Perhaps it's coming from my mistake when writing "s7_cell
heap[INITIAL_HEAP_SIZE]".
Should be "s7_cell heap[INITIAL_HEAP_SIZE*sizeof(s7_cell)]".

A bit more comments on the way the objects would be stored.
As it is now, as far as I understand, s7's heap is contained by
numerous s7_cell[] blocks.
This is because when the heap needs to grow a new block needs to be
allocated (when the existing ones are full).

In this new scheme (pun not indented), s7's heap just grows with a
simple realloc.
An example with cons (simplified):

Simplified heap: [nil, number(1), number(2), cons_a]
cons_a being (1 . ()):
C representation: (car and cdr being now s7_handles instead of pointers)
{.car : number(1) // heap index 1,
 .cdr: nil // heap index 0
}

Addressing Bil's 2 comments about the s7_clone example and the "2 views of s7".
Let's assume the above heap of s7 instance 1, and s7_clone gives us s7
instance 2.
Instance 2's heap would be a copy of instance 1's heap.
So, in c side if we have an s7_handle for cons_a (obtained by s7
instance 1), it'd be just {.index: 3}.
After cloning, the same s7_handle could be used in the cloned s7
instance 2, even if the original s7 instance 1 has freed up cons_a.
Instance 2's heap will still have cons_a in index 3.

Similarly in the s7_clone example I provided, the "fn" is just a
handle, an index to s7_heap. s7_clone gives back a new s7 with its own
heap, but the referenced "fn" will be stored in the same index in its
heap.
 Calling s7_call in sc1 and sc2, each 1 will use their own stored
version of the reference s7 function.

Of course it gets more complicated with symbols, functions etc, since
there are references to char* strings. Only if those were also stored
similarly (as indexes in some storage) then s7_clone could give
completely independent instances.
And last but not least, c_objects is another complex beast regarding
the c_object lifetime and gc cleanup.

On Fri, 23 Sept 2022 at 22:17, <bil at ccrma.stanford.edu> wrote:
>
> I just noticed your s7_clone is not necessarily making a new
> s7 instance -- in this case you'll have two views into
> one s7; if these are in separate threads, the two s7's
> will be colliding in their use of the evaluator -- it
> is not thread safe in the sense that any number of
> threads can be calling into the same s7 instance.
> There's a note about this in s7.html.  And if they aren't
> in separate threads, you've gained nothing by copying
> the array of handles, unless I'm missing something.
>
>