[aquaria] Patch to run Lua scripts as threads

Alec Holowka zaphire at gmail.com
Wed Jul 7 04:17:05 EDT 2010


Hmm yeah. So far it seems like making our own local variable system is the
way to go...

It'd be good  to test it out with a handful of scripts and see what it
does... if it's a big improvement, then we could apply it to everything
else. It'd just take some grunt work. :)

On Tue, Jul 6, 2010 at 9:46 PM, Andrew Church
<achurch+aquaria at achurch.org<achurch%2Baquaria at achurch.org>
> wrote:

> Okay, never mind all that.  It looks like Lua resolves global variable
> references in functions when the function is compiled, not when it's
> called, so you can't set up a nested thread environment and have the
> functions use that.  (Well, you can, but it requires even more hacks.)
> It worked in my original version only because I was always loading the
> script after creating the thread.
>
> Best laid plans, as they say...
>
>  --Andrew Church
>    achurch at achurch.org
>    http://achurch.org/
>
> >Well, the way Lua threads work (as I understand it, anyway) is that each
> >thread is sort of a "lightweight" lua_State, in the sense that when you
> >create it, it shares the global table of the original lua_State you
> >created it from.  But it's still a separate state block, so you can set
> >a new environment table and the thread will then use that instead of the
> >original.
> >
> >Since Lua also lets you link tables together using the "index"
> >metamethod (see under http://www.lua.org/manual/5.1/manual.html#2.8),
> >you can nest environments by setting the thread environment's index
> >metamethod to the original global table -- that way the thread can read
> >from both its own environment and the shared globals, but it can't write
> >to the shared globals so it won't interfere with any other instances of
> >the same script.
> >
> >It looked convenient to me, anyway. (:
> >
> >  --Andrew Church
> >    achurch at achurch.org
> >    http://achurch.org/
> >
> >>I suppose I don't understand the thread method very well, so that may be
> >>hampering my ability to see the advantages/disadvantages to either. :)
> >>
> >>On Tue, Jul 6, 2010 at 6:59 PM, Andrew Church
> >><achurch+aquaria at achurch.org <achurch%2Baquaria at achurch.org><
> achurch%2Baquaria at achurch.org <achurch%252Baquaria at achurch.org>>
> >>> wrote:
> >>
> >>> Just that it feels really roundabout to me, especially with all the
> "v."
> >>> prefixes added to the variables.  As long as we have to set something,
> >>> why not just set it once when the thread is created?  Then you don't
> have
> >>> to worry about updating it later, plus you can use "global" variables
> in
> >>> the scripts without worrying about forgetting a "v." somewhere.
> >>>
> >>>  --Andrew Church
> >>>    achurch at achurch.org
> >>>    http://achurch.org/
> >>>
> >>> >What's wrong with setting a global variable before each script
> function is
> >>> >called?
> >>> >
> >>> >On Tue, Jul 6, 2010 at 6:41 PM, Andrew Church
> >>> ><achurch+aquaria at achurch.org <achurch%2Baquaria at achurch.org> <
> achurch%2Baquaria at achurch.org <achurch%252Baquaria at achurch.org>><
> >>> achurch%2Baquaria at achurch.org <achurch%252Baquaria at achurch.org> <
> achurch%252Baquaria at achurch.org <achurch%25252Baquaria at achurch.org>>>
> >>> >> wrote:
> >>> >
> >>> >> Okay, so I've run into a little problem with this.  I'm not sure
> what
> >>> >> approach your friend took, but what I've done so far is put a
> >>> >> "v = getVars()" at the top of each script, and put "v." in front of
> all
> >>> >> local variables.  The problem is that the functions in each script
> all
> >>> >> see only a single version of "v", because the getVars() is only
> executed
> >>> >> once per script instance.
> >>> >>
> >>> >> I guess one way around this would be to add a getVars() call to
> every
> >>> >> function, but that feels a bit fragile to me -- too easy to miss one
> >>> >> somewhere, and you can't even trace the problem easily because it'll
> >>> >> fall back to the global "v" definition (which you need for
> initializing
> >>> >> stuff at the top of the script).
> >>> >>
> >>> >> What I did for now was to update "v" with the current instance's
> >>> variable
> >>> >> table right before each call into Lua, but that feels like a hack to
> me;
> >>> >> if we have to mess with the Lua environment from C, we might as well
> go
> >>> >> back to the nested environments I was using before, because at least
> >>> with
> >>> >> those you don't have to to a lua_setglobal() on every Lua function
> call.
> >>> >>
> >>> >> I don't know Lua too well, so maybe I'm missing something obvious --
> >>> >> any other suggestions?
> >>> >>
> >>> >>  --Andrew Church
> >>> >>    achurch at achurch.org
> >>> >>    http://achurch.org/
> _______________________________________________
> aquaria mailing list
> aquaria at icculus.org
> http://icculus.org/mailman/listinfo/aquaria
>



-- 
Alec Holowka
www.infiniteammo.ca
www.bit-blot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/aquaria/attachments/20100707/b3e12c8b/attachment.htm>


More information about the aquaria mailing list