mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
3d9e5e68af
The peak-children assertion sampled /proc for children of the slave PID every 50ms and kept the maximum. #1912 called out that a sampled peak is only a lower bound; on the x86-64 farm box it is worse than flaky -- it is deterministically 0, for two compounding reasons measured there: * The slave parent exits as soon as stdin drains and every request is forked (~0.8s into the burst), which reparents the still-running children. ppid attributes a child to the slave only inside that window. * count_children forked an awk per /proc entry per sweep; on a box with ~130 processes one sweep takes ~1.3s -- longer than the entire attribution window. The sampler could not see 20 live children that pgrep showed concurrently. The slave now records the high-water mark of the live-child count by the cap's own accounting, at the only moment it can rise (immediately after a fork), and in harness mode reports PEAK_CHILDREN=<n> on stderr at exit. Production never sets SLAVE_TEST_HARNESS and never reads our stderr, and the report is a single line after stdin EOF. The harness drops the sampler, asserts the reported peak instead, and gains a cap-overrun check (peak > 20 now fails too -- the sampled lower bound could never catch that). The early_fast discriminator -- the deterministic evidence that the cap releases one slot per exit -- is unchanged, now snapshot at a bounded ~2.5s rather than after a sampling loop of unpredictable duration. Verified: 5/5 identical PASS (peak exactly 20) on the box where the old harness was 0/deterministic-FAIL; a 10-request burst reports PEAK_CHILDREN=10 (not pinned at the cap); no env var -> no stderr output. peak >= 20 stays a hard assertion -- the evidence changed, not the bar. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| run_child_cap.sh | ||