Is it safe to reuse buffer for poll_frame?

[OldMansKid]

Hi everyone,
I'm trying to reduce allocations when implementing my custom Body for responses. Currently I'm trying to use this struct:
pub struct SharedBuf { ptr: *const u8, len: usize, pos: usize, } impl Buf for SharedBuf {...}
to point to a BytesMut, and let poll_frame return SharedBuf so I can reuse the BytesMut as the buffer to load data from the disk. But I'm not sure if it's safe to do so, as that would require hyper to have finished using the buffer in a previous call to poll_frame, whenever it calls poll_frame again. I have been attempting this for some time, but I forgot to ask if this is supported at all.

[dswij]

bytes::Bytes and bytes::BytesMut used in hyper have a really good allocation efficiency: https://docs.rs/bytes/latest/bytes/index.html.

But, yes, it's safe. From the docs of bytes::BytesMut:

A unique reference to a contiguous slice of memory.
BytesMut represents a unique view into a potentially shared memory region. Given the uniqueness guarantee, owners of BytesMut handles are able to mutate the memory.
BytesMut can be thought of as containing a buf: Arc<Vec>, an offset into buf, a slice length, and a guarantee that no other BytesMut for the same buf overlaps with its slice. That guarantee means that a write lock is not required.

[seanmonstar]

It could be safe. BytesMut does that when you split and freeze. But it does atomic ref counting to make sure no frozen slices still exist.

If done wrong, it is unsafe and can be Undefined Behavior. If you're doing all that manually, I'd recommend using BytesMut safe methods to do that instead.

[OldMansKid]

Thanks for the replies, but I kind of don't get it. Don't the split functions of BytesMut make it smaller and smaller? Or do you mean
I can achieve reusing BytesMut by doing something like:

//loading file task
let mut reusable = BytesMut::with_capacity(4096);
loop {
    let length = wait_for_poll_frame().await;
    file.read_exact(&mut reusable[0..length]);
    let view = reusable.split_to(length);    
    send_to_poll_frame(view).await;
    reusable.resize(4096); // this doesn't cause allocation?
}

[seanmonstar]

Yes, in that BytesMut, when asked to grow, will check if it can reclaim the parts split off, because all Bytes have been dropped. If they haven't been, because some other code is holding on, then it will make a new allocation instead. To do otherwise would be Undefined.

[seanmonstar]

This is described more here: https://docs.rs/bytes/latest/bytes/struct.BytesMut.html#method.reserve

[OldMansKid]

That's insightful, thanks.