[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Random crashed with threaded application
- From: Javier Guerra Giraldez <javier@...>
- Date: Thu, 20 Jun 2013 17:56:12 -0500
On Thu, Jun 20, 2013 at 4:07 PM, David Demelier
> 2013/6/20 Javier Guerra Giraldez <email@example.com>:
>> On Thu, Jun 20, 2013 at 3:28 PM, Javier Guerra Giraldez
>> <firstname.lastname@example.org> wrote:
>>> you should read/modify/execute a single Lua State concurrently from two threads
>> ... and of course, by "you should..." i really meant "you should NOT...."
> So does the Lua VM store some static variables or so? Why it's not
> supported? My naive thoughts let me understand that if I use the state
> and leave it just like when I found it, it should continue working.
as usual when hitting "send" too quickly, and then quickly correcting
myself, I contribute more to confusion.
let me say it again:
you should NOT read/modify/execute a single Lua State concurrently
from two threads.
as Luiz said, Lua is reentrant, but not threadsafe. Therefore, any
concurrent access to a single Lua State can't be guaranteed to work.
Even if one thread only reads, it might be reading in the middle of an
update performed on other thread, so it could still crash, or give
in conclusion: all Lua API calls must be protected by a mutex tied to
the Lua State. (that's what the global locks mentioned by Luiz do
when compiled with the appropriate preprocessor flags)