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

[Mark Hamburg <mhamburg@...>]

This is more or less exactly what I've wanted. It would make my life easier
building mixed Lua/Objective-C object hierarchies. (It unfortunately doesn't
help on the CLR side but that's because of the more complicated dueling
garbage collectors problem.) One can even implement reference counting on
the C side by using the transition from zero to positive reference count to
add the object to a Lua table and the transition the other way to remove it.
That's a bit expensive but it works.

Stepping back, one could identify the goal as being able to write
userdata-based objects that are equivalent to table-based objects in their
capabilities and role in the Lua universe.

Now, lacking a userdata upvalue mechanism, I'm turning to a scheme in which
the Lua data references a table and the table references the userdata. This
scheme is not secure. The table to userdata reference is hidden behind a
light userdata key, but the link can still be found via table iteration. I
think one could also use a weak-keyed table mapping the Lua table to the
userdata. The methods for the object are accessed via the metatable of the
table part. C methods then need to know about the extra indirection by using
the table to access the userdata. If one were really paranoid, one could
check that the table hasn't been switched when doing this dereference. The
Lua portion of the object is more exposed than it would be with userdata
upvalues, but that's also true for table-based objects. These essentially
are table-based objects. They just happen to have some userdata associated
with them.

With a mechanism like explicit reference counting on the C side, one can
even do things to allow C to keep the object alive beyond the bounds of the
method call if necessary. With a garbage collected environment like the CLR,
I think I end up having to accept that if a userdata value can be kept alive
by the C universe, then it may outlive it's Lua table.

None of this, however, is efficient in terms of space or speed.

Mark

on 6/10/04 2:59 AM, Jamie Webb at j@jmawebb.cjb.net wrote:

> [ userdata upvalues ]