lua-users home
lua-l archive

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

Hi Austin.

On Mon, Jul 14, 2014 at 8:56 AM, Austin Einter <> wrote:
> My worry is, with use of our own locks to protect Lua state , will garbage
> collection pose any thread safety issues.
> Say threads are T1 and T2
> Using lock, I can control T1 and T2, so that only one thread access Lua
> state at a time
> But garbage collection, in which thread context it executes

It executes in the context of the thread you have used to call lua.

Bear in mind Lua is not like, say, the JVM, which creates threads,
including some of them for garbage collection. Lua is just a big
library which manages very sophisticated data structures in a very
sophisticated way. It's is just code and data. It's thread context is
borrowed, I mean, YOU ( your lua hosting code ) have to create a
thread and make it execute lua code. The garbage collector is just a
collection of routines inside the lua chunk, and they cannot excute
unless YOU make a call into one of the lua routines.

> Can it happen that, under T1 I am doing something, and with T2 garbage
> collection is being executed by system......, hence we will not be able to
> protect in this case as garbage collection code is not in my control.

It is in your control. If none of you threads have called a lua
routine, the garbage collector is not executing. If you use a toplevel
mutex, only one of your threads is inside, so either T1 is doing
something unrelated to lua, and t2 can be inside and garbage
collecting, or t1 is inside lua and t2 is outside ( either blocked in
the mutex waiting for t1 to exit lua or doing unrelated things ).

Just treat it as any reentrant library and you'll be OK.

Francisco Olarte.