Scheduler priorities
Slap yourself if
You think priorities are just performance hints and not correctness boundaries.
Why this exists
Scheduler priorities exist because modern UIs compete for limited main-thread time while trying to stay responsive. Not all work is equal, and pretending it is leads to jank, starvation, or subtle logic bugs.
Mental model
A scheduler is a traffic controller, not a queue. Priorities decide which work is allowed to make progress when time is scarce, not which work is more important in theory.
- Work is split into units that can be paused and resumed.
- Each unit is tagged with a priority that affects when it runs.
- Higher-priority work can preempt lower-priority work.
- Lower-priority work may be delayed indefinitely under load.
- Background work starving forever during frequent user input.
- Assuming low-priority work will eventually run.
- Coupling correctness-critical logic to deprioritized tasks.
- Treating priority as a cosmetic performance tweak.
Scheduler priorities control when work is allowed to execute under contention. They don’t just optimize performance — they shape which parts of the system can make progress and which can be paused or starved.
- Business logic running at background priority
- Assuming FIFO execution under concurrency
- Using priorities without understanding preemption
- Blaming the renderer for scheduler behavior
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.