Rollup of 2 pull requests#157858
Conversation
Explain that the weak count doubles as a lock taken by get_mut and downgrade, and that the value 1 is the implicit weak reference owned by the strong references rather than an absence of weak handles.
…r, r=lqd,bjorn3 Refactor libproc_macro: remove * imports This factors out (and goes a bit further) some of the work from rust-lang#157590 which I think can/should be merged independently of the wasm proc macros strategy, since it just makes it easier to read code in the bridge. It was confusing to get warnings/errors when commenting code that looked unused but was actually pulled in due to the `*` imports from other modules. This also factors the panic message into a separate module since it's not really related to `rpc` in a direct sense. Best reviewed by-commit. r? bjorn3 since you've probably at least glanced at this code recently, but happy to re-roll if you'd prefer.
…t, r=joboet alloc: clarify comment on ArcInner::weak lock sentinel The comment on the `weak` field of `ArcInner` currently states that the `usize::MAX` sentinel locks "the ability to upgrade weak pointers or downgrade strong ones", and that this is used to avoid races in `make_mut` and `get_mut`. Both halves of that description are inaccurate. `Weak::upgrade` never inspects the weak count, so the lock has no effect on it. The operation only CASes on the strong count and is happy to succeed while the weak count is locked. `Arc::make_mut` also does not participate in the locking protocol, and the function body already contains a comment noting that observing `usize::MAX` for the weak count there is impossible because only a thread holding a strong reference can take the lock. The lock is actually only taken in `Arc::is_unique` (which backs `Arc::get_mut`), and the only operation that observes and waits on it is `Arc::downgrade`, which spins while `weak == usize::MAX` before attempting its CAS to create a new `Weak`. This PR rewrites the comment to describe what the lock is and what it actually prevents. Closes rust-lang#144296
|
@bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
|
@bors treeopen |
|
Tree is now open for merging. |
|
📌 Perf builds for each rolled up PR:
previous master: edff07ce1a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing edff07c (parent) -> 8d6b380 (this PR) Test differencesShow 418 test diffs418 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 8d6b38095ef12416976655207031eeb4337df71b --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (8d6b380): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 6.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeResults (primary -0.0%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 519.155s -> 517.524s (-0.31%) |
Successful merges:
r? @ghost
Create a similar rollup