lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


You could use environment tables that have a metatable that use the global table as index table.

E.g.
setfenv(fn,setmetatable({},{__index=_G}))

So every function can access global data. You would need to watch out for modifications to shared tables though.

Hope that this helps
--Eike

On Sep 5, 2011 8:01 AM, "Max E" <max@meliaserlow.dyndns.tv> wrote:
> Hello list,
>
> So I'm trying to have all the scripts in my application run in
> separate
> lua threads (although none of them are running concurrently.) I wish to
> do it this way so I can share a single table between all the scripts.
> Besides that, however, I want the scripts to be completely isolated
> (with their own global scopes, etc.) I understand the standard way to do
> this is to use lua_setfenv to set a table as the environment of a Lua
> thread object. What I'm having trouble with is the details.
> I need all the Lua standard libraries available to each thread,
> and I
> need each thread to be able to call 'require' on various files, where
> sometimes a file might be 'required' on multiple threads. Also, it is
> not acceptable for two threads to be able to mess with each others'
> global variables by accident. I have tried two methods:
> Method A: create a table with lua_newtable, set it as the
> environment
> table with lua_setfenv, then call luaL_openlibs on the lua_State I
> originally got from lua_newthread. Problem: the standard libraries don't
> show up; I don't think luaL_openlibs is doing anything.
> Method B: create a deep copy of the main thread's
> LUA_GLOBALSINDEX,
> then set that as the environment table. Problem: although the standard
> libraries show up just fine now, I can only 'require' a file from one
> thread at a time. (And if it's a problem with my deepcopy function, I
> freely admit I'm an idiot.)
> If it cannot be done, I can go back to my old system, which was
> to have
> each script on its own state and use proxies and metamethods to sync up
> the shared table, but this wasn't a perfect solution because it was
> impossible to 100% emulate a "native" table.
>
> SOURCE CODE:
> 1) The relevant part of my C code:
> http://pastebin.com/sRznADVe
> 2) The entire C file, if you want some context:
> http://pastebin.com/Qp8b72F1
> 3) The deepcopy function I'm using:
> http://pastebin.com/UfdyfCDF
>
> I'll provide any other information you want, of course.
>
>
> Thanks preemptively,
> -Max E.
>
>
>