RE: Thread woes

["Joel Pritchett" <jpritchett@...>]

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.

Joel

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] 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 jpritchett@sammystudios.com 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
the
globals to get the "next" function which isn't a great thing to do if
you've
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
used
as a sandbox for an editing/execution environment. Could I avoid these
problems simply by setting the sandbox as the environment for the result
of
compiling each chunk of code? Or should I stick with the approach of
copying
into the sandbox the values that cause problems?

Mark