Re: Require problems in sandboxed thread

["Daniel Collins" <daniel.collins@...>]

> I think this is one of the problems I was trying to 
> articulate a couple of weeks ago. When you say you are 
> creating an environment table I presume that you mean that 
> you are creating a function environment for the  thread (i.e. 
> LUA_GLOBALSINDEX) and this environment is metatabled to the 
> main global environment.

Yes, this is what I am doing. The idea was to keep globals created by
the thread limited to that thread, but to allow the existing global
environment be visible to the thread. By doing this I hoped to save some
memory.

> The problem could be that the first time you call require it 
> compiles and the module and *sets the function environment to 
> the environment of the caller*. Which if the package is using 
> seeall() metables back to LUA_GLOBALSINDEX (your intial 
> thread environment). This means that the second time you call 
> the require(d) functions there is a good chance the function 
> environment for the require(d) functions will not be what you expect.

I don't think this is quite it. The environment of the caller (ie: where
I call require from) is the thread environment, not the global
environment. I create the new thread and set its environment in C code,
then both the lua scripts I posted run in the thread.

Looking at the source code for ll_require, it gets the loaded table
(_LOADED) from the registry. Is the registry common to all threads? I
could try modifying the loadlib.c source so the _LOADED table is stored
in the environment rather than the registry. I will see how this goes.

- DC