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

re: run 3 did not freeze -- a counter-example to my own inducer hypothesis

Browse Source 
Third run with the inducer on from flight start went 900s without freezing, so
the tally is 2 for / 1 against. Stated confound: the inducer was far weaker this
run (~47-50s per CPU pass vs ~4.2s in run 2, because two subagents were
saturating the box -- 22 passes in 15 min instead of ~150). That is consistent
with either reading, so it is not scored as a confirmation. What it does
establish is that the inducer is not sufficient, and that future runs must
report its measured rate rather than just that it was on.

Second healthy stability sample: 9 stable / 14 vary vs 12 / 13 in the first,
intersecting to only 8 threads. So the stable set is run-dependent and must be
measured within the run it is used in -- the same lesson as gdb thread numbering,
one level up.

The frozen half of the distribution experiment is still uncollected.
This commit is contained in:
Sylpheed RE agent
2026-08-25 11:56:00 +00:00
parent d93917bed4
commit 380caf6f88
2 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/data/waitobj-healthy-stability-run2.txt Normal file
View File

@@ -0,0 +1,32 @@
# Second independent healthy stability sample (6 captures, run 3)
=== stability across 6 healthy captures: h1, h2, h3, h4, h5, h6 ===
T106 VARIES -- | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | --
T105 VARIES Wait(XEvent) | -- | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent)
T104 VARIES Wait(XEvent) | -- | -- | Wait(XEvent) | Wait(XEvent) | Wait(XEvent)
T103 VARIES -- | -- | -- | -- | -- | Wait(XEvent)
T97 VARIES Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | --
T96 VARIES Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | -- | --
T80 VARIES -- | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore)
T79 VARIES -- | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore)
T78 VARIES Wait(XEvent) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore) | WaitMultiple(XEvent,XSemaphore)
T77 STABLE Wait(XEvent)
T76 STABLE WaitMultiple(XEvent,XTimer)
T75 VARIES -- | -- | Wait(XSemaphore) | Wait(XSemaphore) | -- | --
T74 VARIES -- | Wait(XSemaphore) | Wait(XSemaphore) | Wait(XSemaphore) | -- | --
T71 VARIES -- | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent) | Wait(XEvent)
T69 VARIES Wait(XSemaphore) | -- | -- | -- | -- | --
T66 STABLE Wait(XEvent)
T65 STABLE WaitMultiple(XEvent,XSemaphore)
T64 STABLE WaitMultiple(XEvent,XSemaphore)
T63 STABLE Wait(XSemaphore)
T62 STABLE Wait(XEvent)
T61 STABLE Wait(XEvent)
T50 VARIES -- | -- | -- | Wait(XEvent) | WaitMultiple(XEvent,XEvent) | --
T36 STABLE WaitMultiple(XEvent,XEvent)
--- 9 stable, 14 vary across healthy play
Only a thread in the STABLE set can carry a frozen-state signature;
a VARIES thread differing when frozen proves nothing.
STABILITY DONE
--- inducing and watching for the freeze (11:39:43)
NO FREEZE

37
docs/re/mission-freeze-resume-spin.md
View File

@@ -1145,3 +1145,40 @@ Compare **distributions**, not samples: N healthy captures vs N frozen ones, and
call a thread a signature only if its frozen distribution lies outside its
healthy range. The harness now does the healthy half; the frozen half needs a run
that freezes while being sampled repeatedly.
## 🔴 2026-08-25 (run 3) — a counter-example to my own inducer hypothesis
Third run, inducer **on from flight start**, watched for **900 s**:
**it did not freeze.** So the tally is now **2 for, 1 against**:
| run | inducer | outcome |
|---|---|---|
| 1 | off 670 s, then on | clean 670 s, frozen **54 s** after it started |
| 2 | on from flight start | frozen **~96 s** |
| 3 | on from flight start | **no freeze in 900 s** |
**A confound, stated rather than used as an excuse:** the inducer was far weaker
this run. Each CPU pass took **~47–50 s** against **~4.2 s** in run 2, because
two analysis subagents were saturating the box, so it completed **22** passes in
15 minutes instead of the ~150 run 2's rate implies. That is consistent with
"less contention reached the emulator, so no freeze" — but it is equally
consistent with "the inducer never mattered and runs 1 and 2 were luck". One run
cannot separate those, and I am not going to score it as a confirmation.
What it does establish: **the inducer is not sufficient**, so any future run must
report the inducer's *measured* rate, not merely that it was enabled.
## 🔴 The STABLE set is itself run-dependent
The second healthy sample (6 more captures, `data/waitobj-healthy-stability-run2.txt`)
gives **9 stable / 14 vary**, against **12 / 13** in the first. Intersecting the
two stable sets leaves **8 threads** — T77, T76, T66, T65, T64, T63, T62, T61.
T80, T79 and T71 were stable in run A and vary in run B; T36 is the reverse.
So the "only a stable thread can carry a signature" rule is right, but the stable
set **must be measured within the run it is used in** — it does not transfer.
That is the same lesson as the gdb thread numbering, one level up: nothing about
thread identity or behaviour carries across runs for free.
**Net for the distribution experiment:** the healthy half now has two independent
samples; the frozen half is **still uncollected**, because run 3 never froze.