The thread that is currently active in the Lua state is the one that will do the garbage collecting
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.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
Keep the stuff you need 'anchored' in the lua state, then it will not be collected.
> 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.
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.
> I have not see any issue, just want to make sure I am not doing wrong in my
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.
BTW; did someone mention that top-posting is considered a bad habit around here?