akiomik / akiomik/bela-rs

probe-init-failure.sh: the busy probe has no interlock now that it really contends

Open
#167 5 comments 0 reactions 0 assignees View on GitHub
bug hardware
Dominant language
Rust
Stars
1
Forks
0
Avg merge
5h 19m
Merged PRs (30d)
26

Description

Until #166 the `busy` probe's holder was launched in a way that blocked
the ssh call for its whole life, so the probe always ran after the
holder had exited and the two never overlapped. With the launch fixed
they do, and three things about the probe's shape become live for the
first time.

**Nothing makes the holder win the race.** The only interlock is the
`sleep 2` between the launch and `run_probe`, so the measurement
depends on the holder's `Bela::new` and `start()` finishing inside it.
If the probe gets there first, it takes the audio system and the holder
takes the `Error::Init(-1)`, and the row reads
`first=rendered-NNNN (holder failed-Init(-1), …)` — which is exactly
the shape of the conclusion #166 retracted.

**Nothing waits for the holder before the oracle behind it.** The probe
now finishes about eleven seconds after the holder starts, where the
holder's own hold ends at about seven and a half. If a holder is slower
than that — a slow teardown is a thing this script exists to
investigate — the trailing `oracle` asks the board for an audio system
while the holder still has it, gets the same refusal, retries after
`RECOVERY_WAIT`, gets it again, and `wedged()` tells the operator to
reboot a board that is fine.

**The second half of the probe cannot measure anything.** `busy-probe`
waits `BUSY_WAIT_SECONDS` and tries again in the same process, but
libbela latches its refusal for the life of a process
(`Bela_isAlreadyRunning`, `core/RtWrappers.cpp`; see "Audio thread" in
`docs/board-facts.md`), so the second attempt cannot succeed however
long it waits — and in practice reports `AudioSystemPoisoned`, because
`Bela::new` refuses first. The wait buys eight seconds per run for a
constant.

What that suggests, in one shape: have the probe's second attempt run
in a fresh process, and make the two ordering assumptions checks rather
than sleeps — the holder's log already says when it is up and when it
is done, and waiting for the latter before the oracle removes the false
wedge as well. That is a change to what the probe does rather than to
what it records, which is why it is not in #166.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.