<div dir="ltr"><div>On Sun, 17 May 2020 at 15:06, Ronie Salgado <<a href="mailto:roniesalg@gmail.com">roniesalg@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>hi Ronie,</div><div> </div><div>The PR that comes to mind essentially did two things: </div><div>1. Moved the native-sleep from the Idle-thread to the DelayScheduler-thread </div><div>2. Added an Idle-flag set in the Idle-thread and reset when the DelayScheduler-thread wakes a delayed-thread.   </div><div><br></div><div>It was based on the following logic...</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>It shouldn't be too hard to recreate, but it may be redundant.  I'd need direction from those working on the IdleVM</div><div><br></div><div>cheers -ben</div><div><br></div></div></div>