RE: Are lua_State's thread safe?

["Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>]

No two scripts can run simultaneously anyway unless you are using
multiple processors.  If you don't need to share Lua data between
threads, then you should defnly use a separate lua_State for each
thread.  Lua is completely reentrant so this will not present any
synchronization problems.  However you will end up using more memory to
account for each lua_State object.

Also look into Lua "threads", which are basically separate lua_States
that can pass data back and forth using lua_xmove.  By having a single
global state and a Lua "thread" for each thread of your program, you can
have threads pass Lua data, but you will then have to consider
synchronization problems again.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of John Klimek
Sent: Wednesday, December 14, 2005 2:46 PM
To: Lua list
Subject: Re: Are lua_State's thread safe?

Thanks for the responses...

Suppose that hundreds of users are trying to execute scripts at the
same time.  Won't the system become very slow because each thread
(each user has it's own thread) is trying to grab ahold of a lock on
the lua manager object?  (and thus each script must run when no other
scripts are running)

Would I be better of creating a brand new lua_State for every single
script as it's running that way each thread/user/script can run
simultaneously with the other scripts?


On 12/14/05, Eric Scouten <scouten@adobe.com> wrote:
> Yes, given this caveat, you can use the same lua_State from multiple
> threads. However, you may not want to.
>
> The most obvious path to being thread-safe is to redefine lua_lock and
> lua_unlock in llimits.h. Our experience suggests that while correct,
> this is a bad idea. You'll spend way too much time in the OS mutex
code.
> (This was observed on MacOS. The threading implementation is based on
> pthreads, so we would expect similar results on many *nix flavors.)
>
> In order for multi-threading to work with Lua, you should either find
a
> relatively course-grained lock/unlock bottleneck or simply use
different
> Lua universes (i.e. lua_States that aren't related to each other).
>
> -Eric
>
>
>
> Dolan, Ryanne Thomas (UMR-Student) wrote:
>
> >You will have to use synchronization techniques such as mutexes to
keep
> >different threads from accessing the lua_State at the same time, or
else
> >you will get unexpected results and crashes.
> >
> >Really you will need to keep threads from accessing your LuaManager
> >object at the same time also for the same reasons.  Anytime a shared
> >variable is manipulated by different threads you need to use
> >synchronization.
> >
> >-----Original Message-----
> >From: lua-bounces@bazar2.conectiva.com.br
> >[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of John Klimek
> >Sent: Wednesday, December 14, 2005 12:28 PM
> >To: Lua list
> >Subject: Are lua_State's thread safe?
> >
> >I'm wondering if I can create a single object (lets call it
> >LuaManager) with a method called RunScript and then have several
> >socket threads share the same object which is sharing the same
> >lua_State.
> >
> >Is this possible?  Is it safe?
> >
> >
> >
>
>
> --
> Eric Scouten | scouten@adobe.com | Photography: www.ericscouten.com
>
>