Revision history for ioRelinquishProcessorForMicroseconds
Additions:
See iPhone
Deletions:
Additions:
delay := Delay forMilliseconds: 1.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
bag sortedCounts
1000 timesRepeat:[bag add: [delay wait] timeToRun].
bag sortedCounts
Deletions:
1000 timesRepeat:[bag add: [delay wait] timeToRun].
Additions:
Testing?
delay := Delay forMilliseconds: 1.
bag := Bag new.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
delay := Delay forMilliseconds: 1.
bag := Bag new.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
Additions:
Older VMs would use getNextWakeupTick and try to figure out a viable time slice as compared to sleep time, this led to complaints about on some systems it would spin at 100% when idle as the sleep time was < time slice and no sleeping would occur.
Additions:
The trade-off here is if sleeping is too short or infrequently, squeak uses too much CPU time to do
Deletions:
Additions:
We use getNextWakeupTick() to find out the next wakeup time for Delay, if in the past, return. If in the future, use it. If zero, set a 16ms wait time. Then we invoke the unix aioSleep logic with that sleep time.
Same as OSXCarbon
Currently it seems to use the bogus value of 1000 microseconds, it first calls ioPoll to service any pending I/O interrupts, then it may call nano-sleep, followed by another call to ioPoll to service any pending, otherwise if Nano-sleep is not available it calls the aioPoll select() logic using the 1000 microsecond value.
Afterwards it will ensure ever 40 milliseconds to invoke setInterruptCheckCounter(-1000) to check for semaphores pending
Same as OSXCarbon
Currently it seems to use the bogus value of 1000 microseconds, it first calls ioPoll to service any pending I/O interrupts, then it may call nano-sleep, followed by another call to ioPoll to service any pending, otherwise if Nano-sleep is not available it calls the aioPoll select() logic using the 1000 microsecond value.
Afterwards it will ensure ever 40 milliseconds to invoke setInterruptCheckCounter(-1000) to check for semaphores pending
Additions:
Without Nano-sleep it seems to sleep for 10 ms. Over the years how this works has changed greatly, also different unix platforms have different ideas about the time slice, lower accuracy linux distributions would have 10 or even 100 ms slices, more modern "REAL TIME" aware linux systems seem to have 1ms slices
Deletions:
Follows unix implementation. uses nano-sleep
Follows unix implementation. uses nano-sleep
Without Nano-sleep it seems to sleep for 10 ms.
Additions:
calls MsgWaitForMultipleObjects using the BOGUS time value, however I believe the windows vm fires a timer every millisecond to wake up to ensure Delays are serviced, so at best it may only sleep for 1 ms (UNCONFIRMED)
For time to time one should check the accuracy of the sleep to ensure Delay forMilliseconds: is not being impacted and the time that you expect to wake up *IS* the time indeed
For time to time one should check the accuracy of the sleep to ensure Delay forMilliseconds: is not being impacted and the time that you expect to wake up *IS* the time indeed
