Skip to content

Add conversion from Bytes to Vec#151

Open
eira-fransham wants to merge 2 commits intotokio-rs:masterfrom
eira-fransham:rebase-into-vec
Open

Add conversion from Bytes to Vec#151
eira-fransham wants to merge 2 commits intotokio-rs:masterfrom
eira-fransham:rebase-into-vec

Conversation

@eira-fransham
Copy link
Copy Markdown
Contributor

@eira-fransham eira-fransham commented Jul 6, 2017

This takes the into_vec function from this PR and makes it work on master. It also extends it with an equivalent BytesMut version and a Into<Vec<u8>> impl for each.

This was referenced Jul 6, 2017
@stepancheg
Copy link
Copy Markdown
Contributor

Public into_vec is probably not needed when From is implemented for Vec.

@eira-fransham
Copy link
Copy Markdown
Contributor Author

I quite like the pattern of having a generic version and a monomorphic function that covers the most common case in order to make type inference nicer, but it's your call.

@stepancheg
Copy link
Copy Markdown
Contributor

I think

  • into_vec can be added any time later, but it can't be removed because of backward compatibility
  • and into_vec may give users wrong idea that operation is cheap, but it is not always cheap

Anyway, it's not exactly my call, because I'm not the maintainer of the library.

@eira-fransham
Copy link
Copy Markdown
Contributor Author

eira-fransham commented Jul 6, 2017

Oh sorry, I got you confused with the maintainer. Yeah, I agree with that thinking. I think the best thing to do here is to keep the function but make it private, since I prefer unsafe code to be contained in inherent impls if possible. I'll wait to see if the maintainer responds though.

@carllerche
Copy link
Copy Markdown
Member

I'm fine w/ adding a conversion -> Vec, but yeah it can't be guaranteed to be cheap in all cases.

@eira-fransham
Copy link
Copy Markdown
Contributor Author

I guess you're right that it gives the wrong impression, I'll drop the pub

This also make `into_vec` methods private and correspondingly fixes up the
doctests for `Bytes::into_vec`.
@eira-fransham
Copy link
Copy Markdown
Contributor Author

@carllerche Any update on this?

Comment thread src/bytes.rs
return r;
}

if kind == KIND_ARC {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading this correctly, this function assumes that a BytesMut handle has a unique Arc<Shared> (no other clones). However, that is not the case. There can be many outstanding handles to the same Arc<Shared>. BytesMut only guarantees that it has exclusive access to a window of the shared buffer. So, it can mutate the bytes in its window, but it does not have exclusive ownership of the buffer.

My guess is this function should be deleted in favor of just always calling Inner2::into_vec.

Comment thread src/bytes.rs
/// // memory is not allocated for the result, it is the same object
/// assert_eq!(ptr, vec.as_slice().as_ptr());
/// ```
fn into_vec(self) -> Vec<u8> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am OK w/ making this public. It's fine to have inherent struct functions as well as From implementations.

Comment thread src/bytes.rs
/// // memory is not allocated for the result, it is the same object
/// assert_eq!(ptr, vec.as_slice().as_ptr());
/// ```
fn into_vec(self) -> Vec<u8> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am OK w/ making this public. It's fine to have inherent struct functions as well as From implementations.

Comment thread src/bytes.rs
}

if kind == KIND_ARC {
let arc = self.arc.load(Relaxed);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment stating that this Relaxed load is safe as we are guaranteed to have exclusive access to the atomic by virtue of the function taking self.

@carllerche
Copy link
Copy Markdown
Member

Thanks for the PR. I added some inline comments.

@carllerche
Copy link
Copy Markdown
Member

Relates to #86

@killme2008
Copy link
Copy Markdown

What's progress of this PR? I think it's really useful for performance critical code. @carllerche

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants