Re: Problem with concurrency, threads, Lua states and maybe GC?

[Jerome Vuarand <jerome.vuarand@...>]

2009/12/1 Javier Guerra <javier@guerrag.com>:
> On Tue, Dec 1, 2009 at 10:48 AM, Matt 'Matic' (Lua) <lua@photon.me.uk> wrote:
>> There is quite a large amount of C/C++ extensions added into Lua that are
>> called from within each Lua context
>>
>> This is probably just a side detail and not relevant.
>
> does any of these extensions touch a Lua_State other than the one that
> called it?  remember that the Lua core calls LuaUnlock just before
> executing a C extension, so some other state will be running
> concurrently with your C code; if you modify it, it will be corrupted.

I had similar issues. If several threads use a given coroutine, Lua C
API calls from different C extensions may be intermixed, and while the
interpreter state itself is safe, the content of the stack may become
wrong. Many luaL_ functions become unsafe in that regard since they
may unlock the state in the middle of processing.

To solve the problem I decided to expose lua_lock and lua_unlock from
the Lua API (I have a patch available somewhere), so that I can call
it around all C code supposed to access shared Lua states. This
implies that lua_lock implementation works recursively, but that's
quite easy to do with most threading APIs.

Another solution not involving patching Lua is to make sure that no
two native threads use the same Lua thread (coroutine). This is why
most threading libraries for Lua create at least one Lua coroutine per
native thread created (eg. LuaThread, LuaProc).