Cross posting since at this level systems are still very similar.

I've sometimes wondered about how the idle process��

relinquishing the CPU interacted with delay scheduling,��

since they operate at the extreme opposite ends of process priorities.

Historically there was...

which had the following performance this for later comparison...
�� ����(1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds].

�� �� ==> "#(2 5 4 2 4 4 2 4 4 3)"

To improve battery life yield time Pharo changed this to 50000 in...��

* https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-idleProcess

* https://github.com/pharo-project/pharo/commit/0b0d12dc

but had a negative impact on delays...��

�� ��==> "#(36 51 50 51 50 51 51 30 50 50)"

as reported... https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly

The problem seems to be that #relinquishProcessorForMicroseconds: suspends the main VM thread for a fixed amount during which expired delays cannot be dealt with.�� I'm not sure of the exact mechanism in the VM but this looks related...

Win: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/win32/vm/sqWin32Window.c#L1593

Mac: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/unix/vm/sqUnixHeartbeat.c#L263��

I'm not sure about Linux

One idea was to have a setting, but another path is to mix the idle-relinquish��

into the delay-scheduling to dynamically relinquish up to exactly��when the activeDelay expires.

I'm now seeking:

* comment on how this might interact with parts of the VM I'm not familiar with.

* help to discover and stress test corner cases.����

* help to determine if there actually is a benefit and characterize what that is,

especially anyone familiar with headless images with reduced UI and I/O events.

I was surprised to see the existing system already often showed 0% CPU usage (in Windows).