[aquaria] Patch to run Lua scripts as threads

Andrew Church achurch+aquaria at achurch.org
Wed Jul 7 02:46:07 EDT 2010


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>
>>> 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>>
>>> >> 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/


More information about the aquaria mailing list