Async queries was Re: [vworld-tech] Re: Database usage
hook_l at pyrogon.com
Sat Feb 14 17:50:05 PST 2004
So the whole async query thing has caused a bit of a design quandary
for me. The simple, straightforward to handle async queries would be
to do something where you iterate over all game objects, allowing them
to 'tick'. If one of them is needs something from the DB, it would do
something like this (in Lua code)
-- Lua supports multiple return values
while true do
lock, status = Lock.get_lock( lock_id )
-- fired off a query that hasn't had its results
-- cached, so we should yeild
if status == 'pending' then
coroutine.yield( self.co, 'waiting' )
The main meta-tick routine iterates over all objects in the world,
letting them tick, and does this until all of them return 'finished'
when they yield. So in a game object tick routine you do something
while true do
coroutine.yield( self.co, 'done')
Which is basically an infinite loop that yields with a 'done' status
when it's done doing internal updates.
Okay, so the world constantly resumes all the coroutines until they
have all reported they're done for that tick.
Easy in theory, but there is a big problem with synchronization
points. Assume you update the world at a fixed tick, and within each
tick different objects have different priorities (e.g. in combat
you're dealing with initiative), then you _can't_ allow some objects
to go before the previous object has completed its tick.
It would seem that this would be a fairly common case -- am I missing
something glaringly obvious, or will there simply be either a bunch of
sync points or, even worse, a bunch of sorting by non-competing
objects into buckets that can be updated safely out of order?
More information about the vworld-tech