[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Distributed Lua
- From: teppy <teppy@...>
- Date: Thu, 07 Jan 2010 19:59:54 -0500
I'm planning to modify Lua for use in an MMO server. The architecture
is similar to the server that runs our current game, "A Tale in the
Desert," but would use Lua as the scripting language.
Each machine in the server cluster would have a number of suspended
Lua threads. It would pick one to run; the running thread could yield
for a variety of reasons, including:
1. The code the thread is running explicitly yields.
2. The code tries to access a table that is not resident on the
machine that the thread is running on.
Case 2 is the interesting one, and is the main modification I need to
make to Lua. When a thread is about execute a VM instruction that would
cause it to access a table that is not resident, that thread would
automatically yield before running the instruction. The server would
then fetch the table, and the thread would then run later. Fetching
tables takes considerable time, so other yielded threads would be
resumed while waiting.
So, I need to determine if my strategy is sound; here are the areas
that I've identified as needing to change, so far:
1. Modify the struct TValue in lobject.h to contain information on
where (which machine in the cluster) to fetch the table from when it is
not resident. This would be in the form of a Global ID that would
uniquely identify the table as well as encode where the table's home
2. Modify the main loop in luaV_execute in lvm.c to yield if it's
about to execute an OP_GETTABLE, OP_SETTABLE, OP_GETGLOBAL or
OP_SETGLOBAL instruction on a table that is not resident. Somewhat
tricky with metatables because you may need >1 table present to execute
one instruction, and that causes deadlock issues. I'd probably just
detect this case and bail.
So my question: Is this basic strategy sound? Any big gotchas that I
may have overlooked?