[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Are lua_State's thread safe?
- From: John Klimek <jklimek@...>
- Date: Mon, 19 Dec 2005 15:56:36 -0500
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:
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])
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
On 12/14/05, Dolan, Ryanne Thomas (UMR-Student) <firstname.lastname@example.org> 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: email@example.com
> [mailto:firstname.lastname@example.org] 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 <email@example.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
> > (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
> > relatively course-grained lock/unlock bottleneck or simply use
> > 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
> > >different threads from accessing the lua_State at the same time, or
> > >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: firstname.lastname@example.org
> > >[mailto:email@example.com] 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 | firstname.lastname@example.org | Photography: www.ericscouten.com