On a 4-thread laptop the background search at nice +10 took a share of the
cores from the chunk workers: 600 chunks arrived 3-4 s later. The thread now
runs only on cores nothing else wants (Linux SCHED_IDLE, macOS background
QoS, Windows idle priority): horizon_threads::idle_current.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On Linux an unprivileged thread can't raise itself, so #1179's render
thread hint does nothing there. The dedicated server already lowered its
helper threads instead (world generation, lighting, connection writers:
10 nice levels, or the idle class). The client now does the same, so the
world-generation and meshing workers (two pools with single player's
server thread) no longer hold the render thread back while terrain loads.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client asks for its render thread what it already asks for the
server thread (vanilla's MinecraftServer.spin): user-interactive QoS on
macOS, above-normal priority on Windows, on machines with more than four
processors. While terrain loads at 32 chunks, the worker pools (two with
single player's server thread), the chunk encoders and other programs
outnumber the cores. A frame that gave its core up in queue.submit then
waited 10 to 200 ms to get one back: the long frames of #678.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MinecraftServer.spin raises its server thread (Thread.setPriority(8)) when
there are more than four processors. The new horizon-threads crate makes the
same request for the dedicated server's thread and the integrated server's:
user-interactive QoS on macOS, above-normal priority on Windows, nothing on
Linux (an unprivileged thread can't raise itself).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ludovic Marie
rdbtCVS