feat: add SIRUN_READY_FD ready signal to exclude startup time#80
Merged
Conversation
RUSAGE_CHILDREN only updates after a child exits and is waited for, so the rusage snapshot taken at signal time is identical to the original baseline. Only wall.time and instructions (Linux) are post-ready; document this accurately in README and spec.
rochdev
marked this pull request as ready for review
June 3, 2026 21:13
bengl
reviewed
Jun 4, 2026
The pipe already signals child exit via EOF when the write end closes, so racing the pipe against child.status() is unnecessary. Sequential await is simpler and removes the futures dependency entirely.
bengl
previously approved these changes
Jun 4, 2026
This comment has been minimized.
This comment has been minimized.
bengl
previously approved these changes
Jun 4, 2026
…ed CI flakiness on macOS) async_std::fs::File on macOS uses kqueue-based I/O: when the pipe event fires, the async task is rescheduled through the executor before resuming. That extra scheduling hop means proc_pidinfo is called slightly later than with spawn_blocking, which uses a dedicated OS thread that calls proc_pidinfo synchronously right after the read returns with no scheduler hop in between. On a loaded CI runner that window is large enough for the process state to change, causing proc_pidinfo to return None and the CPU subtraction to be skipped.
rochdev
force-pushed
the
rochdev/ready-signal
branch
from
June 4, 2026 17:40
8e6173e to
afee830
Compare
…SAGE_CHILDREN The bash fixture used $(seq 1 300000) which forks a subprocess — seq's CPU accumulates in RUSAGE_CHILDREN transitively but is invisible to proc_pidinfo which only measures bash's own task. The mismatch caused cpu.pct.wall.time > 100% on ~74% of macOS CI runs. Python keeps all CPU in a single process with no fork/exec after signaling, so proc_pidinfo and RUSAGE_CHILDREN always agree.
rochdev
marked this pull request as draft
June 4, 2026 20:00
…ne_byte CI failures were caused by the bash fixture's subprocess CPU leaking into RUSAGE_CHILDREN, not by the read mechanism. Both approaches pass the 100x test with the Python3 fixture.
rochdev
marked this pull request as ready for review
June 4, 2026 20:18
bengl
approved these changes
Jun 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SIRUN_READY_FDenv var: Sirun always provides a writable pipe fd to every benchmarked processwall.time,user.time,system.time,cpu.pct.wall.time, and (Linux)instructionsto measure only the post-ready period/proc/{pid}/staton Linux,proc_pidinfoon macOS) and subtracted from the finalRUSAGE_CHILDRENdeltamax.res.sizealways covers the full process lifetime (kernel-tracked peak, cannot be sampled mid-run)Usage
Test Plan
cargo testpasses (all tests includingready_signal_resets_wall_timeandready_signal_cpu_pct_bounded)wall.timeis near-zero after 500ms startup sleep + ready signal (examples/ready-signal.json)cpu.pct.wall.time <= 100%after CPU-intensive startup + ready signal (examples/ready-signal-cpu.json)SIRUN_READY_FDusage are unaffected🤖 Generated with Claude Code