Additions:
See iPhone
Deletions:
TBD
Additions:
delay := Delay forMilliseconds: 1.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
bag sortedCounts
Deletions:
delay := Delay forMilliseconds: 1.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
Additions:
Testing?
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:
The trade-off here is if sleeping occurs too infrequently, squeak uses too much CPU time to do
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
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
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
sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds)
Parms: microSeconds, ignore it, it's wrong a constant of 1000
return: NONE, fake return of zero
From: Interpreter
Why:
Make the VM sleep for some milliseconds
Responsibility:
In the past this routine slept for some number of milliseconds, 10, 100? This was wrong
and John
McIntosh lobbied to change the logic to sleep until the next wakeup tick.
Then it was noticed we did not service UI or socket events timely. So the aioPoll
call was added to ensure we would wake up if a UI or other interrupt arrived. We
also set setInterruptCheckCounter to zero to indicate that on the next check for interrupts
we should find a Delay to service.
The trade-off here is if sleeping occurs too infrequently, squeak uses too much CPU time to do
nothing. If it sleeps too much then UI performance may suffer (which might not be noticed), or a
delay might not get serviced in a timely fashion (interesting side-effects), or a socket connection not serviced, that can be noticed
by Seaside.
Developers should carefully consider the trade off between sleeping and timely waking. Note that Morphic wants to wake up every 16 milliseconds to do nothing so there is always a pending delay, however pre-morphic the next wakeup time could have been zero?
MacIntosh
Follows unix implementation. uses nano-sleep
os-9/OSXCarbon
Follows unix implementation. uses nano-sleep
Cocoa:
TBD
iPhone
Follows unix implementation. uses nano-sleep
Unix
Without Nano-sleep it seems to sleep for 10 ms.
Windows
BUGS