[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Running a script in each Lua thread.
- From: "Steven Brekelmans" <sbrekelm@...>
- Date: Sat, 18 Oct 2003 19:18:54 -0700
Thank you for the example code. I'd read about this technique in the
archives but hadn't been able to put the pieces together myself.
Is the setup of the table a one time thing that I have to do when creating a
new thread? Do I need to perform any special operations to make sure it is
GC'd? Also, is the call to get_table before each resume to push the thread's
table into the global space? I'm still so new to this and appreciate the
help so much.
[mailto:firstname.lastname@example.org]On Behalf Of Kevin Baca
Sent: Saturday, October 18, 2003 4:40 PM
To: 'Lua list'
Subject: RE: Running a script in each Lua thread.
The docs on this are a little vague:
Each thread has an independent global environment table. When you create
a thread, this table is the same as that of the given state, but you can
change each one independently.
Where it says "you can change each one independently" that means you can
*replace* each one independently.
IOW, each thread can have a unique global table, but it's up to you to
actually give each thread a unique global table.
Here's some code that demonstrates this:
lua_State* LA = lua_open();
luaopen_base( LA ); //get the base lib
lua_State* LB = lua_newthread( LA );
//LB is an independent thread, but its globals
//table is still the same as LA's globals table,
//so we'll replace it with a new table.
//The new table is set up so it will still look
//to LA's globals for items it doesn't contain.
lua_newtable( LB ); //new globals table
lua_newtable( LB ); //metatable
lua_pushliteral( LB, "__index" );
lua_pushvalue( LB, LUA_GLOBALSINDEX ); //original globals
lua_settable( LB, -3 );
lua_setmetatable( LB, -2 );
lua_replace( LB, LUA_GLOBALSINDEX ); //replace LB's globals
//Two scripts, each with a doit() function
lua_dofile( LA, "scriptA.lua" );
lua_pushliteral( LA, "doit" );
lua_gettable( LA, LUA_GLOBALSINDEX );
lua_resume( LA, 0 );
lua_dofile( LB, "scriptB.lua" );
lua_pushliteral( LB, "doit" );
lua_gettable( LB, LUA_GLOBALSINDEX );
lua_resume( LB, 0 );
print( "Script A" )
print( "Script B" )
Hope that helps.
> I've searched through the archives and it has been very
> useful in getting me started with lua. I'm at a bit of an
> impass right now and am hoping someone on the list can help.
> Currently I am opening a lua_State, registering all of my C
> functions with that, and then creating a new thread for each
> entity I need using lua_newthread(). Subsequent to creatring
> a new thread, I load a script to be run by that thread, and
> then use lua_getglobal(thread, "funcname") to find the
> function I want to call in the script. then I call
> lua_resume(). This works perfectly as long as the function
> name is unique. The problem is I would like to have each
> script have an Initialize() function. Unfortunately, the
> Initialize() lua function of whichever script was last loaded
> gets called no matter which lua thread I am resuming.
> What is the proper way of doing this? My application, like so
> many others, is in a game system where I would like to be
> able to create new game entities, attach a lua script to
> then, and let the script run, using
> from within C functions to yield the scripts. I also would
> like to keep my function names identical across all scripts
> to simplify the calling interface from C code. I've tried
> using multiple lua_open() calls to create seperate lua_States
> for each entity, but then I have to register my C Functions
> for each new entity. This seems somewhat expensive since we
> are targetting the console market where memory and speed are
> a key requirement.
> I've seen some details in the archives but they all use
> lua_cobegin() a function that is no longer available in lua-5.0.
> Any tips or even pointers to previous message threads about
> this would be great. If worse comes the worse I can create a
> new lua_State using lua_open() for each object, but that
> seems like too much overhead, what with having to register
> the C functions each time.
> Many thanks for your time.
> Steven Brekelmans