I'm curious/lazy here, I stuck this pattern in the Morphic event  
control loop years back to achieve the 60 fps morphic update rate.
However as someone finally discovered last year this had sideeffect,  
on an MC server it would stop responding because it was discovered
the higher priority UI loop would run the calculation of waitTime  
which was <= 0  Then it would not run the Delay which hung any
incoming lower priority MC queries, and as we know, swirling the mouse  
restored sanity.

On a (Delay forMilliseconds: x) where x is <= 0 does it let other  
lower priority processes run for a bit?

On Feb 27, 2008, at 11:38 PM, Andreas Raab wrote:
> I am not sure why your architecture has to change dramatically as a  
> result. If your main problem is to make sure that that a loop is  
> done every 20msecs and you need to adjust for statistical delay  
> variations, you can simply compute the actual time the wait took and  
> do something like:
>
> nextDesiredTick := Time millisecondClockValue + 20.
> [true] whileTrue:[
>   self doControl.
>   "note: for very, very long doControl the waitTime could be negative.
>    you have to decide whether it's better to skip or to run an extra
>    doControl in this case."
>   waitTime := nextDesiredTick - Time millisecondClockValue.
>   (Delay forMilliseconds: waitTime) wait.
>   "Next desired tick is twenty msecs from last one"
>   nextDesiredTick := nextDesiredTick + 20.
> ].

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================