docs(rules): correct the RANDOM and extdebug claims with measurements - #1364
Merged
Merged
Conversation
Two claims were relied on while planning performance work. Both are wrong, and one of the proposed corrections is wrong too. RANDOM. The rules said a Bash 3 subshell inherits the RANDOM state, and gave that as the reason a --parallel worker cannot mint a unique token. The issue's correction -- that bash reseeds RANDOM per subshell on every supported version -- holds in a plain shell but not in the context the claim is about: plain shell, 3.00.22 / 3.2.57 / 4.4 / 5.2 / 5.3 three reads differ --parallel worker, Linux 3.0 and 5.2 three reads differ --parallel worker, macOS 3.2.57 three reads IDENTICAL So RANDOM is neither reliably shared nor reliably reseeded: it depends on the platform and on nesting depth. The ordinal scheme (#851) stands, for a stronger reason than either version of the claim. Nothing is asserted about RANDOM in a test, because pinning either direction would make one platform red; `$$` inheritance, which is the half the design rests on, is pinned. extdebug. `shopt -u extdebug` clears errtrace and functrace on newer builds, silently turning off what --strict error tracing runs on. The issue put the boundary at 5.2; it is 4.4: 3.00.22, 3.2.57, 4.0, 4.1, 4.2, 4.3 leaves them as they were 4.4, 5.2.37, 5.3.15 clears both The table now sits at the two call sites that depend on it, and a test pins it per version -- verified green on 3.0, 4.3, 4.4 and 5.2, so both sides of the boundary are exercised rather than assumed. Closes #1354 Claude-Session: https://claude.ai/code/session_01EXYWTGLjf7qM8Ru3GakDRm
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.
🤔 Background
Related #1354
Two claims in the rules files were relied on while planning performance work. Both are wrong — and for
RANDOM, so is the correction the issue proposes.💡 Changes
RANDOM. The rules said a subshell inherits the state; the issue says bash reseeds per subshell. The second holds in a plain shell but not in the context the claim is about:$( )reads--parallelworker — Linux 3.0, 5.2--parallelworker — macOS 3.2.57So it is neither reliably shared nor reliably reseeded — platform and nesting depth both matter. The ordinal scheme (perf(runner): ordinal result-file naming in parallel workers (drop mktemp+mv per test) #851) stands for a stronger reason than either version of the claim. Deliberately not asserted in a test: pinning either direction would make one platform red.
$$inheritance, the half the design rests on, is pinned.extdebug.shopt -u extdebugclearserrtrace/functrace, silently turning off what--strictruns on. The issue puts the boundary at 5.2; measured, it is 4.4 (4.0–4.3 leave them alone). The table now sits at the two call sites that depend on it, and a test pins it per version — verified green on 3.0, 4.3, 4.4 and 5.2, so both sides of the boundary are exercised.No CHANGELOG entry: contributor rules and comments only.
https://claude.ai/code/session_01EXYWTGLjf7qM8Ru3GakDRm