lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


That's the approach I would tend to adopt.

We went down the shared Lua universe route and the mutex overhead is bad. A
lot of this probably stems from the fact that if the GC is running on
another thread, it may care about the values in your thread's Lua state and
hence even pushing a number onto your own Lua stack has to grab the universe
lock. (That being said, the use of lua_lock in the source code leans to the
conservative side which makes it more likely to be correct but also likely
to be slower than necessary.)

The universe lock also means that only one thread is running Lua code at a
time and if blocking here is a problem then you want to yield the lock
periodically from within the byte-code interpreter loop.

I've toyed with the idea of redefining lua_lock to be:

    if not already locked for this Lua state, then lock the mutex

Defining lua_unlock to do nothing and adding lua_forceunlock. This would
address the issue that most of the expense I was seeing came from unlocking
the mutex only to immediately re-lock it on the same thread. But that gets
mentally complicated.

What would be useful for any system that pools Lua states would be a way to
reset the stack portion of a Lua state back to the state it would be in if
one had just done a lua_open. (We can assume that any evolution in the
globals is desirable to preserve.) The other choice is wrapping things in
lua_cpcall and the like and that complicates the code that wants to grab a
Lua state and use it. I've written one based on studying luaD_pcall, but I'm
only mostly confident that I've gotten everything right since the
interpreter documentation is sketchy. (That's not a complaint about the
interpreter. It just limits the ability of others to make changes.)

Mark

on 7/22/04 9:05 AM, Kevin Baca at lualist@aidiastudios.com wrote:

> If your global state is immutable then, instead of all threads sharing a
> single state, can you have multiple identical lua states, each in its
> own thread?  Maybe a lua state pool?  When you need to call a compute
> function, grab a state from the pool and compute away.
> 
> -Kevin