In theory, all you need to do is provide definitions for lua_lock() and
lua_unlock() (which are currently #defined to be nothing) and recompile Lua.
I have a strong hunch that the use-case behind the lua_lock/lua_unlock macros is fairly different than the one I'm imagining. Specifically, it looks like they're intended for the case where several different C threads may all want to share access to the same lua state, so we might want to compile lua in a way where C calls against a given lua state are thread safe.
Thus, you'd probably implement lua_lock/lua_unlock by sticking a mutex inside the global_State struct, and locking L->l_G->mutex. (You emphatically wouldn't implement it by having a mutex in lua_State though, as that could lead to memory corruption when different states sharing the same global data ran in parallel.)
The use case I'm imagining is quite different though -- I'd like several "child" states, all sharing access the same global state, to be able to run simultaneously. And, again, if I'm reading the code right, that's just not what lua_lock is intended for. I think it *is* what Diego's LuaThread mod was intended to do though, which is why I'm interested in the details of his locking strategy.
-Sven
