bench: keep the warm startup daemon alive and refuse legs the display cannot present #427

Merged

natsukium merged 3 commits from bench/warm-daemon-and-display-state into main 2026-09-25 10:38:59 +09:00

Conversation 0 Commits 3 Files changed 8 +673 -45

natsukium commented 2026-09-25 09:41:53 +09:00

Owner

Copy link

Closes #408.

Warm startup daemon

On macOS the autospawned daemon is a forked child of the client, so stop_launch killed it with each launch's process tree. As a result, every "felis (warm)" launch spawned a fresh daemon. The warm row now primes its daemon with one untimed launch, on a socket first verified to be free, and stop_launch(proc, spare=[daemon]) skips that daemon when it stops later launches. Before every launch, each row checks the daemon: the cold row checks that none is bound, and the warm row checks that the primed pid still is. A failed check ends the row as a recorded failure. Each row records daemon_checked. Both rows are always recorded, because the warm row no longer depends on the cold one.

Display state

envinfo.leg_env() now carries display: {locked, asleep}:

• macOS reads IOConsoleLocked via ioreg and CGDisplayIsAsleep for the main display via osascript.
• Linux reads logind's LockedHint. Sleep is null because there is no reading to take.

A leg whose display cannot present at its start is not launched. A leg whose display cannot present at its end is marked refused. In both cases <name>.env.json records the reason and the console prints it. field.sweep_refused moves a refused leg's artifacts, its .done included, to refused/. It runs before a suite starts and before the report loads a directory, so a late write can neither be charted nor skip the retake. The report note names each refused leg.

Other failure-path hardening that review raised (stale rows after an interrupted retry, process reaping, pid-reuse-safe SIGKILL) is out of scope here and tracked in #426.

Verification

• python3 tools/bench/crossterm_test.py: 261 tests pass on Linux and on the M4 Max.
• Linux: crossterm.py run startup --terminals kitty produced both felis rows with daemon_checked 6/6 and no failure. display was {"locked": false, "asleep": null}.
• macOS (currently locked with the display asleep): envinfo.display_state() returns {'locked': True, 'asleep': True}.

Closes #408. ## Warm startup daemon On macOS the autospawned daemon is a forked child of the client, so `stop_launch` killed it with each launch's process tree. As a result, every "felis (warm)" launch spawned a fresh daemon. The warm row now primes its daemon with one untimed launch, on a socket first verified to be free, and `stop_launch(proc, spare=[daemon])` skips that daemon when it stops later launches. Before every launch, each row checks the daemon: the cold row checks that none is bound, and the warm row checks that the primed pid still is. A failed check ends the row as a recorded failure. Each row records `daemon_checked`. Both rows are always recorded, because the warm row no longer depends on the cold one. ## Display state `envinfo.leg_env()` now carries `display: {locked, asleep}`: - macOS reads `IOConsoleLocked` via `ioreg` and `CGDisplayIsAsleep` for the main display via `osascript`. - Linux reads logind's `LockedHint`. Sleep is `null` because there is no reading to take. A leg whose display cannot present at its start is not launched. A leg whose display cannot present at its end is marked refused. In both cases `<name>.env.json` records the reason and the console prints it. `field.sweep_refused` moves a refused leg's artifacts, its `.done` included, to `refused/`. It runs before a suite starts and before the report loads a directory, so a late write can neither be charted nor skip the retake. The report note names each refused leg. Other failure-path hardening that review raised (stale rows after an interrupted retry, process reaping, pid-reuse-safe SIGKILL) is out of scope here and tracked in #426. ## Verification - `python3 tools/bench/crossterm_test.py`: 261 tests pass on Linux and on the M4 Max. - Linux: `crossterm.py run startup --terminals kitty` produced both felis rows with `daemon_checked` 6/6 and no failure. `display` was `{"locked": false, "asleep": null}`. - macOS (currently locked with the display asleep): `envinfo.display_state()` returns `{'locked': True, 'asleep': True}`.

natsukium added 3 commits 2026-09-25 09:41:53 +09:00

bench: keep the warm startup daemon alive and refuse legs the display cannot present ... 6cd894ee3b

On macOS the felis (warm) startup row never had a warm daemon. The
autospawned daemon is a forked child of the client there, so stopping
each launch's process tree killed it, and the session cleanup between
launches does not autospawn; every "warm" launch spawned a fresh
daemon. The warm row now primes its daemon with one untimed launch on a
socket verified free, and spares that daemon when stopping later
launches, which keeps the autospawn path a user takes (the systemd
hand-off on Linux, the fork on macOS) rather than a harness-started
daemon. Both rows check their daemon before every launch (none for
cold, the primed pid for warm) and fail rather than publish a number
that belongs to the other row. With that check a failed cold row is an
ordinary outcome, and the warm row no longer depends on it, so both
rows are always recorded.

Legs also did not record whether the display could present. Behind the
lock screen or with the display asleep, macOS presents nothing, and
felis's client then spins on failed surface acquires, so the leg's
throughput, CPU and memory describe that loop rather than a terminal
drawing. Every leg sample now carries the lock and sleep state; a leg
that starts dark is not launched, and one that ends dark is marked
refused in its env record. The refusal is enforced from that record
when a suite starts and when the report reads a directory, by moving
the leg's artifacts aside: moving them at the moment of refusal was
rejected because a stopped launch's children (felis's wrapper runs
under the daemon) can still write a result or resume marker afterwards,
and no process cleanup can rule that out. The report names every
refused leg with its reason.

Assisted-by: Claude Code

docs: specify the startup daemon checks and the display-state refusal ... 5aaf0296eb

The harness spec is what a reader checks a published bar against, so it
has to say how the two felis startup rows get their daemon and which
display states void a leg. The refusal also earns a design record: a
flag beside the bar is the obvious alternative, and it fails because the
bar would still sit on the same axis as the presenting ones.

Assisted-by: Claude Code

bench: retake a refused leg when a suite is resumed on its own ... f3acc428bf

A refused leg's late resume marker is only set aside when a suite
starts through crossterm.py; the standalone entry point in suites.py
called the suite directly, so rerunning one suite there skipped the
refused leg instead of retaking it.

Assisted-by: Claude Code

natsukium merged commit 64a5eb249a into main 2026-09-25 10:38:59 +09:00

natsukium deleted branch bench/warm-daemon-and-display-state 2026-09-25 10:39:00 +09:00

natsukium referenced this pull request from a commit 2026-09-25 10:39:00 +09:00

bench: keep the warm startup daemon alive and refuse legs the display cannot present (#427)

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!427

No description provided.