��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