RE: Lua State Thread Safety

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Austin Einter
> Sent: maandag 14 juli 2014 8:56
> To: Lua mailing list
> Subject: Re: Lua State Thread Safety
> 
> Hi Tim
> 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

The thread that is currently active in the Lua state is the one that will do the garbage collecting

> 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.

Keep the stuff you need 'anchored' in the lua state, then it will not be collected.

> 
> I have not see any issue, just want to make sure I am not doing wrong in my
> design.

Generally the tendency of people starting with Lua and multithreading is to stick to the paradigms they know, which is usually the concept of preemptive multithreading by the OS. I find Lua's cooperative model far easier to use. And if that can't be done, consider the option Andrew mentioned; multiple states. 

The lock macros should really only be a last resort, because you will be importing the whole deadlock/racecondition misery of preemptive multithreading into Lua. Because they are fine-grained. If you use your own locks/semaphores, make sure a single call is completed before unlocking again to prevent this.

Thijs

> Austin
> 

BTW; did someone mention that top-posting is considered a bad habit around here?