[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: problems upgrading from 5.0.3 - 5.1 with lua_newthread luaL_reflua_gc and lua_resume
- From: "Jerome Vuarand" <jerome.vuarand@...>
- Date: Tue, 31 Oct 2006 13:19:18 -0500
You can also use threads's address pushed as a lightuserdata as a key, this avoids collisions and you don't have to figure out a way to give unique name to your threads.
-----Message d'origine-----
De : lua-bounces@bazar2.conectiva.com.br [mailto:lua-bounces@bazar2.conectiva.com.br] De la part de Leo Razoumov
Envoyé : 31 octobre 2006 11:03
À : Lua list
Objet : Re: problems upgrading from 5.0.3 - 5.1 with lua_newthread luaL_reflua_gc and lua_resume
Can your reproduce your proeblem without using luabind?
If integer keys in LUA_REGISTRYINDEX are accessed ONLY via references your threads should still be in the registry. If, on the other hand, luabind of something else overrides integer keys directly all bets are off. As a simple workaround, give each thread a unique string name and use it as a key.
--Leo--
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