[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Strange crash when calling lua_call()
- From: Coda Highland <chighland@...>
- Date: Mon, 8 Apr 2013 23:05:54 -0700
On Mon, Apr 8, 2013 at 10:45 PM, Satz Klauer <email@example.com> wrote:
> On Mon, Apr 8, 2013 at 4:24 PM, Coda Highland <firstname.lastname@example.org> wrote:
>> 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.
> OK, but that means a callback, where a function in my LUA-script is
> called asynchronously, isn't possible!? My LUA interpreter is running
> all the time, the script is somehow "endless" (there is of course an
> exit condition but it is intended to do some work for longer time).
> And during this time I need to inject some additional information the
> currently running script has to use...
There are ways to deal with this.
You can use a pull architecture, where your outside code passes
messages into a queue that the Lua code can read from. This method is
the one I prefer because it has the least locking overhead.
You can use a Lua C API function that accesses a shared data
structure, and use a mutex to protect access to that shared data
structure. If you set up your metatables right you can make this
pretty transparent on the script side, so this will feel the most like
writing threaded code in pure C.
You could use coroutines to make the Lua script yield at opportune
points without actually halting the control flow.
There are other options but these are the cleanest I know of.