Re: Keeping program flow moving nicely

[George MacDonald <gmd slip net>]

"Eric M. Monsler" wrote:
> 
> "Timothy M. Shead" wrote:
> >
> (snip)
> > Use gtk_timeout_add() to create a 'timeout' signal that gets called,
> > say, every 100 milliseconds or so.  In your handler for the timeout
> > event you decide whose turn it is and call process_move().
> 
> What is the gtk behavior in this situation, if it takes more than 100 ms
> to do process_move()?  I have no idea if this game does so, but I'm
> curious what would happen.

Dunno about Gtk, but I think X will invoke the timeout routine several
times back-to-back if your service routine is cpu bound until past the
next timeout. If it's important to you then you could write some code to 
test it.

> 
> Some frameworks promise that a periodic callback function will get
> called the correct number of times, even if the callback (or other code)
> causes them to occur far later than they ought.  In those situations, if
> the periodic callback does not have sufficient state awareness to either
> deinstall future calls, or do a quick-return, the result could be
> disastrous (or, in this case, a UI lockup identical to the initial
> problem).

It's pretty simple to track the wall clock and the last time you were 
called, do the math to figure out the delta then react accordingly.
What to do in that circumstance is application specific, sometimes
dropping updates is right, sometimes you want to perform each step
so a user can see each step. You may be able to cancel the timeout
on each service call, and then add a new one after you have completed
servicing the timeout. Another approach would be to use threads, then
you would push the load to a separate thread/process leaving the main
thread to do the event driven GUI. If your "moves" are longer than a
second then perhaps you ought to do it that way anyhow so a user can
"interrupt" the "moves".


You could affect "threading" in your "moves" routine by regularly checking
the wall clock during move calculation, if the move takes to long then
return to let the GUI have a chance to service user input. Sometimes this
is a better approach if you want better control over the scheduling 
algorithm.


-- 
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live!   - gmd slip net (7th Coding Battalion)