Re: Feature request: more integration of Lua and C memory management

[Jamie Webb <j@...>]

On Wednesday 09 June 2004 19:12, Roberto Ierusalimschy wrote:
> > I don't think any scheme with weak tables will work correctly, and it
> > would be too slow anyway
>
> Why? (for both statements...)

A weak-keyed table will prevent a pair from being collected if the value 
contains the only strong reference to the key. Thus, weak tables have the 
same cyclic reference problem as other methods. Thinking about it, it needn't 
be any slower than metatables, but I don't like that much either.

> > That array should be accessible given only a pointer to the userdata,
> > and not the actual Lua object (e.g. by storing the array immediately
> > before the userdata and counting backwards).
>
> The idea of userdata keeping direct references to other Lua objects
> is nice. The original Smalltalk had something quite similar: Objects
> could have an optional "raw" area plus an "array" area. But to make them
> accessible given only a pointer seem dirty and dangerous. (Among other
> things, how to avoid the userdata being collected?)

That problem exists anyway for the raw area. If the C code holds a pointer to 
a userdata and doesn't ensure that it remains live, it could segfault. Adding 
an array part doesn't change that. One could suggest never holding a pointer 
to a userdata and always going through Lua, but that means that Lua can 
become a bottleneck for what would otherwise be pure C code.

Using the luaL_ref system, the raw part of the userdata can hold integer 
reference indexes, so C code can obtain references held by a given userdata 
using only a pointer to that userdata and a single lookup in the array part 
of a table. It's reasonably fast, but of course luaL_ref creates 
uncollectable cycles. 

Using unique metatables, it is necessary to first obtain the userdata object 
(which means either permanently keeping the Lua stack in sync with the 
references used in the C code, or doing table lookups to resolve a pointer), 
then its metatable, then index that metatable to retrieve a reference. Plus 
there's the cost of creating the metatable repeatedly.

One improvement I'm looking into at the moment is providing a function that 
does a faster low-level clone of a Lua table, but that doesn't really address 
the problem. There ought to be a way to create references that is fast, easy 
to code, and correct.

-- Jamie Webb