Async queries was Re: [vworld-tech] Re: Database usage

[Brian Hook]

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' )
   end
   break
end

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 
like this:

function GameObject:tick()
   while true do
      self:do_update_stuff();
      coroutine.yield( self.co, 'done')
   end
end

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?

Brian