[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Thread woes
- From: "Joel Pritchett" <jpritchett@...>
- Date: Mon, 20 Oct 2003 10:33:11 -0700
In our implementation our new thread global table actually contains the
old global table as an element so when something isn't found in the
local table it goes and looks for it in the old global table (which was
most likely the state that spawned the thread).
This is nice for us because we get the ability to have both thread local
data and shared global data and it didn't break any of the behaviors of
lua that we had before we put in out own env tables.
[mailto:email@example.com] On Behalf Of Mark Hamburg
Sent: Thursday, October 16, 2003 4:25 PM
To: Lua list
Subject: Re: Thread woes
on 10/9/03 4:22 PM, Joel Pritchett at firstname.lastname@example.org wrote:
> Ok, the __index thing is really neat and works well
Sorry for the late posting.
One thing I discovered when doing this is that pairs does a rawget on
globals to get the "next" function which isn't a great thing to do if
changed the global environment.
In this case, I was changing the value of LUA_GLOBALSINDEX by calling
lua_replace( L, LUA_GLOBALSINDEX ) and the thread in question was being
as a sandbox for an editing/execution environment. Could I avoid these
problems simply by setting the sandbox as the environment for the result
compiling each chunk of code? Or should I stick with the approach of
into the sandbox the values that cause problems?