Closed Cyborus04 closed 9 months ago
I think there might be an issue with this api: if is_unique
returns true, there is no guarantee that it is still unique immediately after this call, as some other thread can hold the reference to this Bytes
object and clone it while is_unique
check is performed.
Ah, like if it was an Arc<Bytes>
. Strange case, but still an issue. I think changing it to take &mut self
should solve that?
I was thinking about &Bytes
rather than Arc<Bytes>
(Bytes
is Sync
, right?), but yes - taking &mut self
in this method should ensure this never happens (:
Normally you would add a method to the vtable and call it, rather than compare with the different vtables. That makes it more difficult to add more vtables in the future.
Makes sense. One moment, then.
You can add a comment that mentions that this could happen if the Bytes
is used concurrently, but other than that, I don't think the concern that @xonatius mentioned is a problem. You shouldn't use &mut self
just for that reason.
I agreed with the &mut self
change since I have safety on the mind, as I was making this change hoping to later also add a method to get mutable access if the Bytes
is unique. Even then, try_get_mut
(or any other name) could itself take &mut self
instead of this needing to, so I'll still revert it.
I have detailed my motivation for this in hyperium/http#662
Closes #533
This adds the
is_unique
method toBytes
. It checks reference count when backed by (effectively)Arc<Vec<u8>>
, returns true when backed by a vec, and returns false for static slices