Re: Multiple related lua states

[Jose Luis Hidalgo Valiño <joseluis.hidalgo@...>]

Well, I use that code in a ScriptManager class which creates a  
initial lua state, so I can
put in there global variables or functions. Once the initial lua  
state is created, you can add
children with something like this:

	Script *ScriptManager::createScript()
	{
		int top = lua_gettop(L);
		Script *script = 0;
		lua_getfield(L, LUA_REGISTRYINDEX, "Scripts"); // top + 1

		lua_State *thread = lua_newthread(L); // top + 2
		script = new Script(thread); // this is the new lua-state for that  
script

		lua_newtable(L);  // a global table for this script
		lua_newtable(L);  // metatable
		lua_getfenv(L,top+2); // that returns the global table (we are  
going to protect)
		lua_setfield(L, -2, "__index"); // set global table as __index of  
the thread
		lua_setmetatable(L, -2);

		lua_setfenv(L,top+2);  // set env of the new thread

		lua_pushlightuserdata(L, script); // key, the pointer to my own  
Script class
		lua_pushvalue(L, top+2);          // value, the new lua thread.
		lua_rawset(L,top+1); // Scripts table
		lua_settop(L,top);

		_scriptCount++;

		return script;
	}

Script is a class that handles a single lua-state ( in fact it  
doesn't know that is a thread)
By the way, the ScriptManager stores it's children scripts in the  
registry in a table called "Scripts" indexed by the
pointer of  the new Script class instance.

Jose L.



El 24/05/2006, a las 13:49, Luiz Henrique de Figueiredo escribió:

> > Does using lua threads actually imply that I must use a thread?   
> > In the
> > model I am suggesting, only one application is 'live' at a time - you
> > can imagine a main menu with apps hanging off it.  You go into  
> > each app
> > one at a time.  No application concurrency.
> >
> > Can application access the threads global table (and by implication)
> > access another application's data?  Or can this be prottected in the
> > manner you have described with the global table?
>
> If there is no concurrency, then you may try to create a single parent
> state containing your static data and functions and then load each
> "application" into a separate child state for which the global table
> has been changed to an empty table with an __index metamethod pointing
> to the parent global table. All static data will be seen in the child
> state but they'll be protected against wrtiting.
> --lhf