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 is too short or 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?

Testing?
delay := Delay forMilliseconds: 1.
bag := Bag new.
1000 timesRepeat:[bag add: [delay wait] timeToRun].
bag sortedCounts

MacIntosh

os-9/OSXCarbon

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.

Cocoa:
See iPhone

iPhone
Same as OSXCarbon

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

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

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.

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
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki