Repository navigation
fix(vcores): the core-wait escape at 2 s, not 250 ms (#1929) - #2127
Conversation
An escape runs a waiting thread with no virtual core while the holder still runs on it, so two threads share per-core state. On current main the waits that reached 250 ms ended by themselves within 1.2 s, so the 250 ms escape fired 6-8 times a run for nothing. Measured A/B: 0 escapes at 2 s in both rounds, frame times the same or better. The escape stays as a deadlock breaker. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…once (flaky JSONDecodeError) (#2130) `tests/test_release_scripts.py` fails now and then on Linux, as it did on main at 364d199 and on #2127. The failing test is `test_tag_pushed_by_hand_gets_its_release_and_sums`; the stand-in `gh` hits `json.decoder.JSONDecodeError: Expecting value: line 1 column 1` when it reads its state file. The cause: `scripts/release_files.sh check` runs two `gh` calls at the same time (`cmp -s <(sums "$id") <(uploaded "$id")`). Every stand-in call appends itself to `calls` and rewrites the state file with `open(STATE, "w")`. So one call can read the file while the other has just truncated it. The stand-in now: - holds an exclusive `fcntl` lock for the whole call, so calls take turns and no entry in `calls` is lost; - writes its state to a temporary file and moves it into place with `os.replace`. The test is the only thing changed; the release scripts stay as they are. It needs `jq` and only runs on Linux, so this was not run locally; CI checks it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|
Measured after the merge on Linux (Arch, RTX 4090, NVIDIA 615.78.08, headless): the issue's start (fresh profile, Start
The same as on your route: no escapes at 2 s, the longest waits end within 1.2 s, frame times the same within the spread. |
Part of #1929. When a guest thread has waited too long for a virtual core, the scheduler lets it run without one (an "escape"). The holder is still running on that core, so the two threads share per-core state. That race is the risk #1929 is about.
On current main (after 9f42700, "WaitAny's scan makes no vcore checkpoint while it holds mw_lock"), the waits that reach 250 ms end by themselves within about 1.2 s. The 250 ms escape fires anyway, 6-8 times per run. This raises both defaults (
HOS_VCORE_ESCAPE_US,HOS_VCORE_ESCAPE_EQ_US) to 2 s. The escape stays as a deadlock breaker, and either value can still be set from the environment.A/B, measured on current main: 25-minute route (Kokiri Forest, Hyrule Field, Kakariko), RTX 4060 Ti, docked 1440p, two rounds each, alternating.
The longer waits do not show up as longer frames: the worst frame is the same or shorter at 2 s. An earlier A/B with a 5 s escape, before 9f42700, did produce 5 s frames. Those long holds are gone on current main.
🤖 Generated with Claude Code