Add Arc/Rc::strong_count_from_raw - #159098
Conversation
rustbot
added
S-waiting-on-author
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-author
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Can you say more about this? Why do you think that requirement is necessary on these functions? In general, I think I'm OK landing this without the need for users to specify an allocator type; as far as I can tell that has no bearing on the ability to access the strong count. |
The clause came from increment_strong_count and decrement_strong_count, where it holds because those rebuild an Arc<T, Global> through from_raw_in and the decrement path frees through the global allocator. Reading the strong count never builds or drops one, and the allocator lives on the Arc rather than in the allocation, so it does not carry over.
It isn't. I copied it off |
| /// | ||
| /// This method does not consume or drop the `Rc` behind this pointer. To avoid a memory | ||
| /// leak, the pointer must be converted back to an `Rc` using [`Rc::from_raw`] or the | ||
| /// allocation must be released using [`Rc::decrement_strong_count`]. |
There was a problem hiding this comment.
This comment about leaks seems copy/pasted and not relevant to the function at hand.
| /// # Safety | ||
| /// | ||
| /// The pointer must have been obtained through `Rc::into_raw` and must satisfy the | ||
| /// same layout requirements specified in [`Rc::from_raw_in`][from_raw_in]. |
There was a problem hiding this comment.
It doesn't really make sense to say it has to go through into_raw (it's fine to use this with non-Global alloc'd Rc) and from_raw_in is also confusing because we specifically don't have an accurate A parameter here.
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
3 participants
Tracking issue: #157021
Accepted ACP: rust-lang/libs-team#792
Adds
strong_count_from_rawtoArc<T, A>andRc<T, A>. It's the read-only counterpart toincrement_strong_countanddecrement_strong_count: you can read the strong count straight from a raw pointer that came out ofinto_raw, instead of rebuilding the smart pointer (and then having to re-leak or drop it) just to peek at the count.Only the strong count is here. Weak count came up in the ACP thread, and libs-api decided to hold off on it until there's a concrete use case, so it's left out.
There's one spot where I went a different way than the ACP sketch, and I'd like your call on it. The ACP puts the method on the
impl<T: ?Sized, A: Allocator>block, but nothing in the signature mentionsA. A raw pointer frominto_rawhas already thrown the allocator type away, so a plainArc::strong_count_from_raw(ptr)can't inferA, and every caller would be stuck writing a turbofish. I moved it to theA = Globalblock instead, right next toincrement_strong_countanddecrement_strong_count, and gave it the same "allocated by the global allocator" safety clause they use. That keeps the calls clean and matches how the other raw-pointer methods are already grouped. If you'd rather it stayed on the generic block, or want an_invariant alongside it, just say so and I'll redo it.On the body: I read the
strongfield directly, walking back from the data pointer the wayfrom_raw_indoes, rather than rebuilding a throwawayArc/Rcand callingstrong_count. That way the access only touches the counter, not the whole allocation. If you'd prefer thefrom_raw+strong_countversion for consistency with the methods around it, that's an easy swap.