[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Feature request: more integration of Lua and C memory management
- From: Jamie Webb <j@...>
- Date: Thu, 10 Jun 2004 00:53:55 +0100
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
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