Repository navigation
External queue can starve timers/pollers #4228
Description
Activity
I'm not sure why we have a separate State 1. It seems to me all that logic can be directly moved into what is currently State 4+, and we could eliminate State 1 altogether.
But, this seems like a more general problem. We are supposed to hit State 0 every 64 ticks, but if every time we obtain work externally (e.g. stealing) we reset the state to 4, then we lose track of our current tick. Maybe we need to track the ticks separately?
There definitely was a reason to have a separate state 1 at some point, but I can't remember right now. We've evolved a lot since then. Taking a glance at the Tokio state machine would probably answer the question pretty quickly, since I think their scheduling algorithm hasn't changed much in the past few years.
As an aside, I think we need to poll (and hit the timers) at line 668, before we transition back to state 4. It's okay that we don't pick it up right away, but giving those events a chance to surface is obviously important. It's also important that the external queue stuff hits the local queue ahead of anything which may be coming from kernel events, since we spill compute work to the external queue, so it takes on a relatively high priority.
- linked a pull request that will close this issueRefactor `WorkerThread` runloop; avoid pathological starvation of pollers #4247
on Jan 21, 2025
If the local queue becomes empty, the worker transitions to checking the external queue.
cats-effect/core/jvm/src/main/scala/cats/effect/unsafe/WorkerThread.scala
Lines 824 to 827 in a49a028
If it finds work there, it will immediately transition back to crunching the local queue.
cats-effect/core/jvm/src/main/scala/cats/effect/unsafe/WorkerThread.scala
Lines 668 to 669 in a49a028
This offers no opportunity to fire timers or poll for I/O.