By the release of Pharo 7 the idle time was increased to 50 ms in order to reduce the CPU usage on the cloud and reduce costs. If I remember correctly Ben Coman did a PR that changes the way the delays are scheduled in order to select the most appropriate time for sleeping, but since the PR was to close to a Pharo release, it was decided to not be included for safeness reasons. We should resurrect that change soon because the default latency is really bad.
hi Ronie,
The PR that comes to mind essentially did two things:
1. Moved the native-sleep from the Idle-thread to the DelayScheduler-thread
2. Added an Idle-flag set in the Idle-thread and reset when the DelayScheduler-thread wakes a delayed-thread.
It was based on the following logic...
1. When the existing Idle-thread is running, its knows that there are no other runable threads and so should native-sleep. However there are probably some delays that expire soon, but the Idle-thread doesn't know when, so it native-sleeps for a fixed period - possibly sleeping past a delay expiry.
2. If the Idle-thread were to send messages to discover how long until the next delay-expiry, that could race with an actual delay-expiry firing the timingSemaphore to premptively wake the DelayScheduler-thread, which subsequently wakes the delayed-thread - and I couldn't reason through the combination of multithreaded line-by-line sequences.
3. It simplified things to ensure there is only ONE sequence to reason about... where the only thing the Idle-thread does is set an Idle-flag then immediately fire the timingSemaphore to invoke the DelayScheduler-thread. When that sees the Idle-flag it native-sleeps the appropriate time until the next delay expiry. Upon waking from that it immediately schedules the delayed-thread and resets the Idle-flag.
It shouldn't be too hard to recreate, but it may be redundant. I'd need direction from those working on the IdleVM
cheers -ben
Locked
