Re: Managing states

["Thomas Tong" <toes@...>]

Yes and no, each thread has it's own VM since each thread own's it's
own LUA state, and of course it's own callstack.

Since the LUA programs run serially, they don't fumble each other up. 
So it does the following.

LuaManager -->
         Sets LUA state to Program1's --- Runs LuaProgram1   
         Sets LUA state to Program2's --- Runs LuaProgram2   
         Sets LUA state to Program3's --- Runs LuaProgram3   
      etc.

-- Performance and error handling isn't an issue right now.  You
essentially give the LUA thread a certain amount of time to run or give
up control.  If it goes over it's allocated time, it gets killed for
being a bad script, whoever wrote it gets his hand chopped off.
probably me ;) 

Other than the thread switch over-head, putting it together this way
doesn't incur any performance over head.  Even then you can stagger
each script's time slice, so that you don't do 10 thread switchs per
update.  I've load-tested it with 50+ scripts running various tasks in
the background and the time required to switch between them is fairly
insignificant.

Thomas
-------------------------
This is a single vm / multiple thread solution if I'm reading
your description correctly?

What about a multithreaded version of Lua?  Is that on the horizon?

To get around this myself in Windows, I've been experimenting 
around with compiling the Lua src into a cross platform executable 
format such as elf, and then loading it manually into memory
on a per thread basis.  My application requires a single
Lua lib, one process, multiple threads all executing at the same time.

I like the time slice idea, except - you have to call that suspend
callback
to give up control.  If a programmer doesn't do this - well, your
program could lock up or fail.  Plus, performance isn't very good 
if you have say, 10 scripts running at the same time.

Regards,
Jim Mathies