struct Unique: Copy more from std and use for Rav1dPictureDataComponentInner::ptr to make it Send + Sync
#1327
Conversation
| pub fn wrap_buf<BD: BitDepth>(buf: &mut [BD::Pixel], stride: usize) -> Self { | ||
| let buf = AsBytes::as_bytes_mut(buf); | ||
| let ptr = NonNull::new(buf.as_mut_ptr()).unwrap(); | ||
| let ptr = Unique::from_ref_mut(buf).cast(); |
There was a problem hiding this comment.
How is this unique in the wrap_buf case? We're borrowing a reference to this data, right? So should we really use unique here?
There was a problem hiding this comment.
A &mut reference is always unique. So it can be &mut or owned. core::ptr::Unique impls From<&mut T> even.
There was a problem hiding this comment.
But once that constructor returns the borrow is over, unless there's a lifetime. So it's no longer unique? How do we ensure no where else has a pointer to the same thing?
| NonNull::new(self.as_strided_byte_mut_ptr().cast()) | ||
| let ptr = NonNull::new(self.as_strided_byte_mut_ptr()).unwrap(); | ||
| // SAFETY: The `ptr` originally comes from a `Unique` in `Rav1dPictureDataComponentInner::ptr`. | ||
| let ptr = unsafe { Unique::new(ptr) }; |
There was a problem hiding this comment.
Again, how is this unique? Can this method return a NonNull instead?
There was a problem hiding this comment.
Because self.as_strided_byte_mut_ptr() is derived from Rav1dPictureDataComponentInner::ptr, which is a Unique. I can say that more explicitly if that's clearer.
There was a problem hiding this comment.
Does that mean there's two Uniques pointing to the same data? The original and the one into the middle?
There was a problem hiding this comment.
e.g. can I just call this twice and get two Uniques? Doesn't that violate the invariants?
There was a problem hiding this comment.
Ugh, yeah, you're right.
Why does core::ptr::Unique: Copy + Clone then?
|
To follow up on the discussion of "should |
…he `Unique` from `CBox::from_c` to the API boundary.
…t is `Send + Sync`.
kkysen
force-pushed
the
kkysen/Rav1dPictureDataComponentInner-ptr-Unique
branch
from
64390bb to
5366e5a
Compare
Co-authored-by: Stephen Crane <sjc@immunant.com>
kkysen
force-pushed
the
kkysen/Rav1dPictureDataComponentInner-ptr-Unique
branch
from
5366e5a to
4369d09
Compare
2 participants
We may be able to replace
SendSyncNonNullwithUnique, but we can do that later. They have basically the same APIs, though slightly different safety invariants (uniqueness vs. thread-safe).