Repository navigation
fix(daemon): more native tasks spend over 250 ms of CPU in one poll #4072
Description
Found while fixing #4066 (PR #4071). A sampler on the debug long-poll guard (from #3997) recorded a backtrace every 2 ms of CPU spent inside one native poll during an mcp_suite run, including the daemons it spawns. These tasks spent more CPU inside single polls than the three sites #4071 fixed:
daemon/bootstrap.rs:835, about 1.1 s across the run.session_temporal_refresh_scheduler/registry.rs:372.code_index_scheduler/activation.rs:315.
They don't trip the guard at moderate load, but under host load they will, the same way the #4066 sites did. Move each one's synchronous work onto the blocking pool so the poll only waits. The sampler is scratchpad/diag4066c.rs, and scratchpad/sym4066.py symbolizes its output. Both are in the coordinator's scratchpad; the PR that fixes this should commit a reusable version.
Activity
ScriptedAlchemy commentedon Oct 16, 2026
Closing as not planned. The remaining native-poll hogs listed here were tracked to satisfy the debug long-poll guard, which failed tasks after their poll had finished. #4076 replaces the assert with a warning and a per-site counter (long_native_polls) plus a scheduling-lateness canary, and floors daemon run and serve at two native workers. The daemon and MCP suites now report only two sites past 100 ms: full_owner_mount.rs:38 (compute) and session_temporal_refresh_scheduler registry.rs:372 (parked). Any move off the worker should start from that data.