Re: Are lua_State's thread safe?

[John Klimek <jklimek@...>]

I'm still confused on a couple of things...

1) Let's say I have 100 players online plus many objects (rooms,
items, etc) that each have a script associated with them.  If I create
a LuaManager (eg. lua_state) object for each one of them, we are
talking about a TON of lua_states.  If I create a state only when a
script is run, then lua_states are being created/destroyed over and
over again (seems like this would be very slow).

2) Threads sound like a good way to go but I'm confused about global
data.  Right now I have a global userdata object called "Connection"
that is SUPPOSED to store the current player connection but every time
a new player logs on, the global variable gets overwritten.

What I'd like is whenever a player runs a script, it's "instance"
(state? session?  whatever it's called) will contain a local copy of
"Connection" that references the player running the script.  Likewise
for NPC or Item/Room scripts... (eg. a "Room" userdata could contain
the current room/item/npc running the current script).

3) Lastly, I need to setup some way to store functions to call them
later on.  For example, consider this lua code:

function sayHello()
  Connection:Send("Hello there."); -- when the function is stored, my
local copy of "Connection" will be lost I think... (right now it's
global, but I can't keep it that way I don't think [read above])
end

Connection:addPrompt("Press enter to say hello.", sayHello);


The last line (Connection:addPrompt) calls my host program and the
host program stores the location of the function inside the Lua
registry (using a numbered index system I made up).  Later on, when
the user presses enter, my host program will get the function from the
lua registry and then execute it.  However, if I use global
"Connection" variables this will screw everything up because we won't
know which "Connection" is currently executing the script... (unless I
refresh the "Connection" userdata every time a script is run....)


As a sidenote, how do I load a lua script file and only run a function
inside of it?  (and NOT run the whole script)


Sorry for the long e-mail...  any help what-so-ever would be GREATLY
appriciated.


On 12/14/05, Dolan, Ryanne Thomas (UMR-Student) <rtdmr6@umr.edu> wrote:
> 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
> >
> >
>
>