Re: lua_lock

[David Jeske <jeske@...>]

On Fri, Nov 14, 1997 at 12:51:07PM -0200, Luiz Henrique de Figueiredo wrote:
> >From Mark@nlcc.demon.co.uk Fri Nov 14 12:47:31 1997
> >
> >In message <9711131905.AA12546@exu.inf.puc-rio.br> lua-l@tecgraf.puc-rio.br writes:
> > >   The Lua reference mechanism (Section 5.6 of the manual) has an
> > > option that allows C to keep a reference to a Lua object without preventing
> > > the GC to collect the object. Does anyone use this option? It was supposed
> > > to be useful in breaking 'reference cicles', when C keeps a reference to a
> > > Lua object and Lua keeps a reference to the C object (userdata), and then they
> > > would be never collected. But we are not sure whether anyone ever succeed in
> > > using it...
> >
> >Am I right in thinking that you are *not* proposing deletion of the lua_ref
> >mechanism, whereby a host program can create tables for it's own use, protect
> >them from the GC and hide them from Lua, whilst still exploiting lua_*
> >functions to do associative lookups within them? I do this a lot.
> 
> We're *not* proposing deletion of the lua_ref mechanism.
> What we want to know is if anyone uses ref's *without locking them*.
> The application you mention is *exactly* what the lua_ref mechanism was designed
> for -- in you case, you lock the values to protect them for GC.
> So, does anyone use unlocked references?

I use unlocked references frequently. I want to keep a faster reference to
something than having to look it up repeatedly. However, I don't want to
hold on to something which has been deleted. So I do a several table deep
lookup once and hold the lua_ref. If the ref goes invalid later, I know
that the entry was deleted from lua.

This dosn't provide me exactly what I _want_, because I really want to
hold a ref to the slot which points to the entity, not the entity itself.
Currently, if someone just _moves_ the entity, but does not delete it, my
C program will incorrectly continue to call it.

Example:

Lua tables:

objects
   object_a
      tick_method  = a_method
   object_b 
      tick_method  = a_method2


So the first time I do the lookup starting at the top "objects" global
variable. I hold the lua_ref to "tick_method" in the respective C++
"object mirrors". Each time the tick is supposed to be called, I deref the
lua_ref, and if it's still valid, I call the tick method. 

However, if some code did the following:

objects.object_c = {};
objects.object_c = objects.object_b.tick_method;
objects.object_b.tick_method = nil;

Then my "mirror" for object_b would still call "a_method2" even though
object_b.tick_method was nil. I know I could hold the ref to "object_b"
instead, but then I would have to perform the hash lookup for the method
each time, and that's not acceptable.

Using lua_lock would be even worse. Then if the method was removed
"correctly" (i.e. don't do cross-assignment as above), it would STILL
persist because of the C lock.

However, I would like it if was easy to lock items so they could not be
modified (with table entry granulatity). I know I could do this with
fallbacks, however, I don't want to take the performance hit for a
fallback and looking in yet another table or data-structure to see if the
value can be changed or not. (Perhaps this would not hurt as much as it
seems, but that's my feeling)

However, I can see reasons for lua_lock, particular with pushing foreign
objects into lua "as" native objects. I considered making my "mirrored"
objects (where there is actually a full C++ object and a full Lua object,
and they just represent the same item in my program) use fallbacks to make
the C++ object "show up" as a native Lua object instead. If that were the
case, I would certainly want to be able to use lua_lock. I would not want
to recreate the code for doing lua hash lookup and variable storage/usage.
So I would create a table in Lua-space which the C++ object would have a
locked reference to. It would not be accessable indirectly, and it
wouldn't be removable. Yet it would exist in the Lua environment.

This would solve all of my problems with "possibly inconsistant data", and
if I get time, I'll reimplement the Lua/C++ object relationships this way.


-- 
David Jeske (N9LCA) + jeske@chat.net