lua-users home
lua-l archive

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


Thumbing through the 5.1 ref manual, I tried this instead of luaL_ref:

      lua_setfield(L, LUA_GLOBALSINDEX, "bok");

and it seems to work (my thread is not garbage collected).

I don't like the string lookup, and I also wonder about the best way to generate a unique string-per-thread (just convert the thread ptr to string??).  seems hacky, I really liked the luaL_ref way of doing this...   I'd still be very interested to hear  what people know about all this, and what way (other than the stack) should I ref my threads to save them from the perils of the GC.

thanks. :-)

On 10/31/06, subatomic <kevin@subatomicglue.com> wrote:
Hi, I have a small game engine that uses coroutines to run each game "actor" (NPC) as a lua class which concurently with many other game actors (think 200+ lua threads)...

My problem is that my threads in 5.1 are being garbage collected, while in 5.0.3 they are not.
I am using luaL_ref to "save" the thread from being collected until I want it to be, then I use luaL_unref.
This doesn't seem to be working in 5.1, but worked ok in 5.0.3.
I was wondering if there's a new way to do this now in 5.1,
or if there is something new about the GC in 5.1 that I don't understand?

My code goes sort of like this:

t = lua_newthread( L );
thread_reference = luaL_ref( L, LUA_REGISTRYINDEX );
     
// then some luabind stuff to construct the new actor script
luabind::object class_constructor_function = luabind::globals(t)[classname];
mMyActor = luabind::call_function<Actor*>( class_constructor_function );
mActorObj = luabind::object( t, mMyActor );

// then push the function and resume the thread for the first time:
mActorObj.push(t);          
lua_pushstring(t, "__call");
lua_gettable(t, -2);  
lua_remove(t, -2);   
mActorObj.push(t);     
resume_status = lua_resume(t, 1);

// then garbage collect (we want performance in the game to be predictable as possible)
lua_gc(L,LUA_GCCOLLECT,0);

// then next frame, resume again
// (here it crashes because 't' has been deleted by lua_gc)
resume_status = lua_resume( t, 0 );


Here 't' has been deleted, I know because I can see 0xfeeefeee's appear inside 't', which happen when I step over the lua_gc statement...

This did not happen in 5.0.3.  But does happen in 5.1

I don't want to leave the (many) threads on the stack, in case I overflow the stack size (my code does work when leaving the thread on the stack, so i know everything else is ok...)...
Any ideas?
thanks!!


(want to play with my code?  see here: http://www.subatomicglue.com/download/luacoroutines.tgz   note: this version has luaL_ref commented out, so you'd need to put it back to play with it...)

--
http://www.subatomicglue.com



--
Kevin Meinert
http://www.subatomicglue.com