[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Scalability of Lua, many small vs. few big lua_States?
- From: Andrew Starks <andrew.starks@...>
- Date: Mon, 27 Jan 2014 12:48:23 -0600
On Monday, January 27, 2014, Dirk Laurie <firstname.lastname@example.org> wrote:
2014-01-27 Dirk Zoller <email@example.com>:
> Think of a spreadsheet where in some cells the user can run a script to
> process data. A lua_State is created per line. People build larger setups
> than the developer anticipated. Typically, each script terminates within
> micros. Yet there are many and they are called frequently.
> It runs on a 16 cpu server. It runs well, load is nicely balanced. Problems
> are spurious lockups or crashes. I want to simplify it. It has grown to
> Now if I redesign it to use fewer lua_States that would be nicer. But I'd
> rather not then see performance hickups come in and learn that the original
> design was actually better.
A lua_State is simply a thread, and if you are only accessing it via
library it is idiomatic Lua (=nice) even if you have a huge table of coroutines.
If it ain't broke, don't fix it.
Sounds like it is at least breaking. :)
I've found that a socket interface works really well with coroutines and that a mix of the two is an almost transparent interface to "services" (not so much objects) that are in the existing lua_state, another thread or across a socket.
But so far, this is a wip for me. I fear that any detail would contain bad advice.