Task starvation
Slap yourself if
You think starvation only happens with infinite loops or that yielding 'sometimes' is enough.
Why this exists
Because many production UIs freeze without long tasks, without errors, and without obvious bugs — starvation is the invisible cause.
Mental model
Starvation is not slowness. It is priority abuse. Lower-priority work never runs because higher-priority work never stops scheduling itself.
- A high-priority queue (often microtasks) keeps refilling itself.
- Lower-priority queues never get a chance to execute.
- Rendering, input, or I/O are deferred indefinitely.
- The system appears idle but is logically blocked.
- Promise chains that recursively enqueue microtasks.
- Async loops that never cross a macrotask boundary.
- State updates scheduled in microtasks inside observers.
- Mistaking starvation for a rendering or framework bug.
Task starvation occurs when higher-priority tasks continuously enqueue themselves, preventing lower-priority tasks like rendering or input from ever running.
- Equates starvation with infinite loops.
- Talks about CPU usage instead of scheduling.
- Cannot explain why no long task appears.
- Suggests debouncing as a universal fix.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.