Correct ... I prefer to use my own lock as i usually have additional non Lua state i need to protect
On Jul 13, 2014, at 7:46 PM, Austin Einter <firstname.lastname@example.org> wrote:2. Do not define lua_lock/lua_unlock, have my own semaphore with count 1, do lock and unlock while accessing lua state.1. By defining lua_lock/lua_unlockI can do it in two waysThanks AllI understand, I need to protect Lua state myself.
If I follow approach 2 (have my own semaphore also I do lock/unlock while accessing lua state), will there be any issue.I do not see any issue as out of two threads only one thread will be accessing lua state.
Now, my doubt is, when garbage collection happens, it executes in which thread context.Since lua_lock and lua_unlock is not defined, can it cause any issue during garbage collection.
Out of two approaches, if I prefer approach 1, will it more slower.Best RegardsAustin
On Mon, Jul 14, 2014 at 7:40 AM, Andrew Starks <email@example.com> wrote:You define lua_lock/lua_unlock, providing your os-specific mechanism.On Sun, Jul 13, 2014 at 8:46 PM, Tim Hill <firstname.lastname@example.org> wrote:
You have to do this yourself.
On Jul 13, 2014, at 5:39 PM, Thiago L. <email@example.com> wrote:
> On 13/07/14 09:36 PM, Austin Einter wrote:
>> Hi All
>> Suppose I have Lua State L as a global variable in my C program.
>> If it is accessed and used by two different threads, is it required for me to protect the Lua State by using a semaphore/mutex.
>> Lua State internally has a semaphore/mutex to protect itself.
>> Please let me know.
> I'm pretty sure they aren't thread-safe...
This will slow Lua down during garbage collection and also generally. If you can, avoid doing that.Lua is reenterant, so running multiple Lua_States is no problem. If you can, run one Lua state per-thread and marshal values between, doing the message-passing yourself, or using ZMQ or NanoMSG or similar.-Andrew