[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
|