RE: GC and threads

["Hassink, Brian" <BHassink@...>]

Thanks for the response. Here's a bit more background on what I'm doing...

I first create a global state using lua_open(). Subsequently, I create C++ objects that have zero or more associated Lua scripts. For each script I create a thread under the global state using lua_newthread(), which loads and initializes the script using luaL_loadfile() and lua_pcall(). At this point, the script is blocked on a lua_yield() waiting for an event to occur.

There are no hard references to the thread on the Lua side as far as I know. I was under the impression, perhaps falsely, that a thread will not be garbage collected if it's status is not dead (i.e. it's currently suspended and waiting to be resumed). In any case, the crash I'm experiencing occurs on the invocation of lua_pcall() after a script is loaded by a new thread. Here's a GDB backtrace...

Program received signal SIGSEGV, Segmentation fault.
0x0046fcb2 in newkey ()
(gdb) bt
#0  0x0046fcb2 in newkey ()
#1  0x0046d6db in luaV_settable ()
#2  0x0046e3a7 in luaV_execute ()
#3  0x00464b2d in luaD_call ()
#4  0x004661f1 in f_call ()
#5  0x00464200 in luaD_rawrunprotected ()
#6  0x00464f28 in luaD_pcall ()
#7  0x00466264 in lua_pcall ()
#8  0x0044c06c in SvcScript::spawn(ObjBase*, std::string const&)

If this is somehow related to not having a hard reference to the thread on the Lua side, how would one go about creating a hard reference given that I'm creating threads via the C API.  

Lastly, the life span of a thread is dependent on the life span of its associated C++ object. So when a C++ object is destroyed, I want to invalidate any associated threads (i.e. status is dead) so that they will eventually be garbage collected. My preference is to do this through a C API call of some sort rather than resuming the thread with a special parameter that tells it to exits its main loop.

Any pointers?

Cheers,
Brian


-----Original Message-----
From: Bilyk, Alex [mailto:ABilyk@maxis.com]
Sent: Tuesday, April 27, 2004 6:05 PM
To: Lua list
Subject: RE: GC and threads


Who holds references to your Lua threads on Lua side? If you don't explicitely create some hard reference to your threads on Lua side they will be GCed without you knowing it. You might be crashing because of this.

What is the life-span of C++ objects vs Lua threads? Do they have the same life span? Do you intend them to have the same life-span? Usually, when you aggregate two objects that depend on each other with their life, you would have to make sure they die together or in some otherwise controlled fashion.

I make Lua do the cleanup in my code because usually there is no controll over the referencing of Lua objects. So, whenever Lua side is GCed my C++ side gets deallocated too (via GC event of a C++ userdata associated with the Lua object), not the other way around.

Alex


>-----Original Message-----
>From: Hassink, Brian [mailto:BHassink@Ciena.com]
>Sent: Tuesday, April 27, 2004 1:31 PM
>To: 'lua@bazar2.conectiva.com.br'
>Subject: GC and threads
>
>
>Hi,
>
>If I have a thread that is currently blocked on a lua_yield() 
>call, is there a way to invalidate the thread (via the C API) 
>such that it will be garbage collected?
>
>I'm creating and destroying C++ objects that have Lua threads 
>associated with them. When a C++ object is destroyed, it's 
>associated Lua thread will never resume, and I suspect will 
>never be garbage collected as a result. I'd like to avoid 
>passing in a special parameter via the lua_resume() call to 
>tell the thread to exit it's main loop.
>
>I'm experiencing a crash in Lua after roughly 50 threads are 
>orphaned as described above, and I try to create more.
>
>Cheers,
>Brian