lua_lock/lua_unlock

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

lua_lock/lua_unlock

David Gish
Hello All,

I'm porting a video game that uses Lua 5.0. The interpreter frequently crashes on startup and the evidence points to a reference counting bug or perhaps simple data corruption. The game uses true preemptive threads, but Lua is only called from the main thread, and I understand that within Lua "threads" are just cooperative coroutines. Anyway, I noticed that the lua_lock() and lua_unlock() macros don't generate any code. This is hardly surprising since both are defined as ((void) 0) -- see http://www.lua.org/source/5.0/src_lstate.h.html

I apologize for being a complete Lua newbie and also for not having read the voluminous archives, but can anyone tell me what's going on with these macros? I read in one posting how someone solved a problem with them, but I must confess I don't get it.

Many thanks,

David Gish


Reply | Threaded
Open this post in threaded view
|

Re: lua_lock/lua_unlock

Ashwin Hirschi-2

I'm porting a video game that uses Lua 5.0. The interpreter frequently
crashes on startup and the evidence points to a reference counting bug
or perhaps simple data corruption. The game uses true preemptive
threads, but Lua is only called from the main thread, and I understand
that within Lua "threads" are just cooperative coroutines.

The lua_lock/lua_unlock pair is there to help synchronise access to Lua states.

Typically, in a scenario where multiple (OS) threads need access to the same Lua state, you'll have to redefine these primitives to something sensible, like locking/unlocking a mutex (or somesuch).

But in your case, it looks like you can leave things as they are, since access from one OS thread is safe.

I'm not sure what you meant by (possible) reference counting bug, though. If I'm not mistaken Lua doesn't use any reference counting...

Anyways, if you suspect the crash during startup is somehow Lua-related, it might be a good idea to review the code that registers the various custom Lua primitives (if any). If the custom init code is sloppy it could (perhaps?) overflow the (Lua VM) stack.

Good luck hunting down that bug!

Ashwin.
--
no signature is a signature