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

[Jamie Webb <j@...>]

On Friday 11 June 2004 15:35, Roberto Ierusalimschy wrote:
> > A weak-keyed table will prevent a pair from being collected if the
> > value contains the only strong reference to the key.
>
> Do you have real examples where that happen?

No.

> > The array should be accessible given only a pointer to the userdata
> > [...]
> > Everything is fine as long as a pointer to a userdata is never stored
> > without a corresponding reference in the array part.
>
> If you have the reference, why do you need access to the array with the
> pointer? Why can't you use the reference?

I needn't have the reference. For example, suppose I register a callback with 
some other library, and that library will pass along a void pointer for me to 
keep state in. Probably I'll need to have a struct like this:

struct MyState {
    lua_State* L;
    MyClass* cls; // This is a pointer to a userdata
};

And that's all the information I have when the callback runs. No way to get at 
the array part (for example to hand off to a Lua callback), except via the 
pointer. Of course, I could maintain a lookup table in the registry, but then 
that's two extra table accesses on creation, destruction, and use. Or, I 
could keep the userdata on the stack and add an extra struct member to record 
where, but that breaks encapsulation somewhat, and it wouldn't be practical 
if there are lots of callbacks registered. It's possible to 'leave the 
reference behind' in various other ways too, and usually the lookup table is 
the most practical solution.

I can't think of any situation in which it would be really disasterous to have 
to first obtain the userdata. It's just not the most useful behaviour: it 
means a bunch of extra bookkeeping in order to get information that Lua 
already knows. Arguably, it would be more general and consistent to have a 
separate lua_pushuserdata and then for the array operations to use the 
reference. That just means two extra stack operations for an array access, 
which isn't too big a deal.

-- Jamie Webb