[squeak-dev] Delay time question

Robert F. Scheer rfscheer at speakeasy.net
Thu Feb 28 06:53:07 UTC 2008


Thanks, this is very helpful.  

I had just checked with a little C program to see that CLOCKS_PER_SEC on
my system(s) is 1000000 so that shouldn't be the limiter.  

I have a feeling that my robot is about to go down the rabbit hole.

- Robert

On Wed, 2008-02-27 at 21:17 -0800, John M McIntosh wrote:
> On Feb 27, 2008, at 9:50 PM, Robert F. Scheer wrote:
> 
> > Time millisecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds:  
> > 10)
> > wait]]  13405
> >
> > Time millisecondsToRun: [10000 timesRepeat: [(Delay forMilliseconds:  
> > 1)
> > wait]]  45728
> 
> For the curious the os-x carbon vm does
> 
> Time millisecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds:  
> 10) wait]]  10196
> 
> Time millisecondsToRun: [10000 timesRepeat: [(Delay forMilliseconds:  
> 1) wait]]  100916
> 
> The place you need to look at is your platform's
> 
> int ioRelinquishProcessorForMicroseconds(int microSeconds) {
> 	/* This operation is platform dependent. 	 */
> 
> 
> Yes very platform dependent, and VM flavour dependent.
> 
> When you do the code above you really are saying gee let's sleep alot.  
> Then ioRelinquishProcessorForMicroseconds
> runs to judge when next best to wake up to service the end of the  
> Delay.  Also on unix if  the operating system says the increment for  
> process switch
> is oh 10 milliseconds then why you cannot actually sleep for 1 ms.
> 
> Time to break out the debugger and your source code reader and  
> carefully examine what ioRelinquishProcessorForMicroseconds()
> is doing.
> 
> In the far past we would just put the VM to sleep for 10 ms or 1 ms,  
> but a few years back I changed that to put the vm to sleep upto the  
> next point where it needed to wake up (we know that because we know at  
> what time delays will trigger in the future). Tempering that is code  
> that aborts the sleep if a keyboard/file handle/someting interrupt  
> comes in, so  that can be serviced right away.
> 
> --
> = 
> = 
> = 
> ========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> = 
> = 
> = 
> ========================================================================
> 
> 
> 
> 




More information about the Squeak-dev mailing list