Revision [116]
This is an old revision of ioRelinquishProcessorForMicroseconds made by JohnMcIntosh on 2008-10-14 23:58:56.
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
os-9/OSXCarbon
Cocoa:
TBD
iPhone
Unix
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
Windows
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)
BUGS
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
