lua_lock

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

lua_lock

Roberto Ierusalimschy
  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...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lua_lock

Veijo Vilva
On Thu, Nov 13, 1997 at 05:05:48PM -0200, Roberto Ierusalimschy wrote:
>   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...
> 
> -- Roberto
> 

  I have used it to achieve a moderate speed-up in a bytecode interpreter
  iterating over largish datasets.

  Instead of

      lua_callfunction(lua_getglobal("my_lua_function"))

  I have 

      lua_callfunction(ref_to_my_lua_function)

  within the innermost loop.
      
    Veijo

-- 
 Veijo Vilva                        [hidden email]
 Dept. Animal Science               http://xiron.pc.helsinki.fi/people/vilva
 P.O.Box 28                         PGP public key available on ./vvpgp.html
 FIN-00014 University of Helsinki   Tel. +358 9 708 5584 | key ID = 6511C0AD

Reply | Threaded
Open this post in threaded view
|

Lua locals

Russell Y. Webb
Hello, again.  Did anyone get my last message about locals?  Sorry to 
repost if it was just too uninteresting to respond to.

I'm wondering why Lua defaults to global for variable access in 
functions.  Most of the time local default is what I need and polluting 
the global space unintentionally can lead to some difficult bugs.  I know 
one can just stick a 'local' in front of everything, but one can also 
program without functons using a goto.

I have two suggestions:
1.  could some form of fallback govern local vs. global defaults?  this 
probably isn't the best way.
2.  how about a new function declaration keyword, say 'method', which 
defaults to local access and a new keyword 'global' that gives you access 
to globals from within functions:
	x=10
	method test()
		print(x)        -- error
		x='a string'    -- global x=10 still
		print(x)        -- prints 'a string'
                print(global x) -- prints 10
	end

Russ

Reply | Threaded
Open this post in threaded view
|

Re: lua_lock

Mark Ian Barlow
In reply to this post by Roberto Ierusalimschy
In message <9711131905.AA12546@...> [hidden email] 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.

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    [hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: lua_lock

Luiz Henrique de Figueiredo
In reply to this post by Roberto Ierusalimschy
>From [hidden email] Fri Nov 14 12:47:31 1997
>
>In message <9711131905.AA12546@...> [hidden email] 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?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua locals

David Jeske-2
In reply to this post by Russell Y. Webb
On Fri, Nov 14, 1997 at 11:53:51AM -0200, [hidden email] wrote:
> Hello, again.  Did anyone get my last message about locals?  Sorry to 
> repost if it was just too uninteresting to respond to.
> 
> I'm wondering why Lua defaults to global for variable access in 
> functions.  Most of the time local default is what I need and polluting 
> the global space unintentionally can lead to some difficult bugs.  I know 
> one can just stick a 'local' in front of everything, but one can also 
> program without functons using a goto.

I agree 100%. However, I think the reason things are the way they are is
to preserve the "script like" or "configuration file" like syntax of Lua.
It would be really annoying when using lua to load configuration data to
have to have a ".programrc" file have "global" before every variable.

> I have two suggestions:
> 1.  could some form of fallback govern local vs. global defaults?  this 
> probably isn't the best way.

Actually, this could be quite usefull. Especially combined with a
standard function for requesting context... For example, a configuration
file could just have a bunch of variable sets, and depending on the
current fallback, they would be routes to the appropriate context.
However, one could "use(my_object)" to change the context or something.

You can _almost_ get this behavior right now with the global variable
fallbacks. However, you have no way of knowing what the "current" context
is as far as I know. Not to mention, there is no "standard" way to define
what the current context might be. One person might call the current
context the local variables of a function, while another might refer to a
table (i.e. proto-object) of the method the current context.

I suspect that with a function written in C one could get at the local
variables of the current function (and the arguments). So you could look
at the "self" variable if you want the current context to be the table
(proto-object). If you want it to be the current function's local variable
scope, it is probably a little tricker. ??


Of course "local" would always give you a local variable still.

> 2.  how about a new function declaration keyword, say 'method', which 
> defaults to local access and a new keyword 'global' that gives you access 
> to globals from within functions:
> 	x=10
> 	method test()
> 		print(x)        -- error
> 		x='a string'    -- global x=10 still
> 		print(x)        -- prints 'a string'
>                 print(global x) -- prints 10
> 	end

I would definetly make use of this. However, I can't help but feel perhaps
there is a better way.

-- 
David Jeske (N9LCA) + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lua_lock

David Jeske-2
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Nov 14, 1997 at 12:51:07PM -0200, Luiz Henrique de Figueiredo wrote:
> >From [hidden email] Fri Nov 14 12:47:31 1997
> >
> >In message <9711131905.AA12546@...> [hidden email] 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) + [hidden email]