fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: WITHDRAW the (A)-press finding -- three emulators were live at once

Browse Source 
While chasing the draw-stream question I found THREE xenia instances running
simultaneously (started 15:39, 15:44, 16:12), which violates the "one emulator at
a time" hard rule and confounds the finding I recorded last iteration.

All three read the same /tmp/xenia_pad.txt and share display :98. A press written
to that file is delivered to EVERY instance, while `screenshot` grabs whichever
window is topmost -- not necessarily the one that acted on it. So "(A) was
delivered and the screen did not change" may simply be two different emulators,
and the keystroke-level confirmation proves only that SOME instance received it.
The navigation.md entry claiming the boot title's "2 of 2" is no longer 2 of 2 is
withdrawn as unsupported, pending a clean re-run.

The cause was mine. run-canary's lockfile is the IMPLEMENTATION of the one-at-a-
time rule; a kill -9 orphans it, and the obvious unblock -- rm -f the lock --
also disables the guard for every later launch. I did that more than once today.

METHOD gains two entries. A lockfile is the rule, not an obstacle to it: clear a
stale lock only after confirming zero live instances, and COUNT them rather than
trusting a kill landed, because a plain kill is asynchronous and a -9 on a stuck
process can take seconds. When a guard blocks you, the question is whether the
condition it guards against is present, not how to remove the guard.

And a third instance of pgrep -f matching the shell that runs it -- this time it
killed a cleanup command halfway through, leaving the emulators alive and the
lock in place. Already recorded for wait-loops; promoted to "reach for -C first".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 16:20:24 +00:00
parent 21de7841da
commit 969b816aad
4 changed files with 123 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/game/navigation.md
View File

@@ -321,7 +321,21 @@ Traps that read as bugs but are not, all measured ✅:
if you must use `-9`, `rm -f /tmp/xenia-canary.lock` after. **And assert the
emulator is alive before entering any wait loop** — `ps -C xenia_canary` — so
the loop cannot spend its whole deadline on nothing.
* 🔴 **Ⓐ on a settled boot title does NOT reliably reach the menu.** This page's
* 🔴🔴 **THE ENTRY BELOW IS WITHDRAWN — the experiment was confounded.** When it
ran, **three emulators were live at once** (started 15:39, 15:44 and 16:12 on
2026-08-30), all reading the same `/tmp/xenia_pad.txt` and sharing display `:98`.
A press written to that file is delivered to **every** instance, and `screenshot`
grabs whichever window is topmost — which need not be the one that acted on it.
So "Ⓐ was delivered and the screen did not change" may simply be *two different
emulators*, and the keystroke-level confirmation proves only that **some**
instance received it. ⚠️ The cause was mine: `run-canary`'s lockfile is the
implementation of the "one emulator at a time" rule, and I had been clearing it
with `rm -f` to get past a stale one — which disables the guard for the next
launch too. **Clear a stale lock only after confirming zero live instances**
(`ps -C xenia_canary --no-headers | wc -l`). The claim below is unsupported and
needs a clean re-run before anyone relies on it.
* ~~🔴 **Ⓐ on a settled boot title does NOT reliably reach the menu.**~~ This page's
§1 and `canary-scripted-input-traps.md` record "the boot title accepts a single
Ⓐ (2 of 2 runs)". A run on 2026-08-30 gated on the **plate pulse** (glyph in
[500, 2500] held 12 consecutive samples), fired at t=484.5 s with glyph 1723 —