lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Apr 8, 2013 at 2:08 AM, Satz Klauer <satzklauer@googlemail.com> wrote:
> On Mon, Apr 8, 2013 at 9:15 AM, Kevin Martin <kev82@khn.org.uk> wrote:
>> This is what I don't understand. You have protected the Lua-C calls, but these calls
>> must be called from somewhere, is that somewhere protected by the same mutex, if
>> not then the state can be accessed by both that thread, and your mutex protected
>> threads.
>
> The C-code is called out of running LUA-script, they are executed in
> thread context of the script. All these C-functions are encapsulated
> by one global mutex (lock at the beginning of the function, unlock
> before returning from it).
>
> The other C-code, that calls back into my LUA-code, is running into an
> owns threads context (I can't change that, this behaviour is defined
> by the underlying library I use). But the C-callback, that is called
> from the library and that performs the lua_call() is encapsulated by
> the same mutex like the other functions mentioned above.

This isn't going to work.

The Lua VM isn't threadsafe. You cannot have multiple threads
accessing any part of the VM at the same time. Your locking scheme
isn't good enough. If you want to access Lua from multiple threads,
you need to lock your global lock every time you invoke the Lua
interpreter, and never let go of it until it's done. And if you do
that, you don't NEED to lock any C callback functions invoked from
Lua, because the lock will already be established.

/s/ Adam