Re: Lua State Thread Safety

Thanks All

I understand, I need to protect Lua state myself.

I can do it in two ways

1. By defining lua_lock/lua_unlock

2. Do not define lua_lock/lua_unlock, have my own semaphore with count 1, do lock and unlock while accessing lua state.

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 Regards

Austin

On Mon, Jul 14, 2014 at 7:40 AM, Andrew Starks <andrew.starks@trms.com> wrote:

On Sun, Jul 13, 2014 at 8:46 PM, Tim Hill <drtimhill@gmail.com> wrote:

On Jul 13, 2014, at 5:39 PM, Thiago L. <fakedme@gmail.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.
>>
>> OR
>>
>> Lua State internally has a semaphore/mutex to protect itself.
>>
>> Please let me know.
>>
>> Austin
> I'm pretty sure they aren't thread-safe...
>

You have to do this yourself.

—Tim

You define lua_lock/lua_unlock, providing your os-specific mechanism.

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