Git Product home page Git Product logo

Comments (6)

seanmonstar avatar seanmonstar commented on September 27, 2024

Bytes always stores all of its data as a single contiguous slice. So, are you asking for a way to easily allocate a new buffer and copy all the bytes into it?

Or do you mean combine without allocation? In that case, perhaps you'd want to reach for an impl Buf, which doesn't promise to be a single contiguous slice. A simple one exists within the crate, Chain. But new ones can be implemented too.

If you mean a 3rd option of combining specifically in Bytes, but without an allocation, I don't see how that could be possible.

from bytes.

juliusl avatar juliusl commented on September 27, 2024

@seanmonstar I meant combine without allocation, so I think Chain is what I'm looking for!

However, re: the 3rd option,

Say I have a big BytesMut that I am splitting off into smaller blocks. At some point I want to grab a range that might span over multiple blocks.

Now, say I have those blocks, I can order them, so technically underneath the hood they are all part of the same contiguous chunk. In this case, would it be feasible to create a Bytes by using the pointer information from the first and last block?

from bytes.

seanmonstar avatar seanmonstar commented on September 27, 2024

It might be possible, but not with the methods exposed today. And I wouldn't recommend depending on the internal details to do it externally.

from bytes.

Darksonn avatar Darksonn commented on September 27, 2024

The bytes crate has an unsplit method.

I don't think we can otherwise support this, so I will close the feature request.

from bytes.

juliusl avatar juliusl commented on September 27, 2024

@seanmonstar definitely, I wouldn't try to hack that together externally.

But I was thinking about how with try_reclaim and unsplit, the original BytesMut is able to know that the reclaimed memory has no more references, so in the other direction would you be able to create a Bytes from the allocated memory space.

(@Darksonn I was hoping to just articulate the idea a bit more, so sorry to comment on a closed issue)

Basically, if I had an imaginary api like:

impl BytesMut {
  fn view_allocated(&self, offset: usize, len: usize) -> Option<Bytes>;
}

Would the owning BytesMut be able to know that all bytes along that range were frozen, such that returning a Bytes for that range would be safe.

from bytes.

Darksonn avatar Darksonn commented on September 27, 2024

No, BytesMut does not know which regions are frozen and which are part of a BytesMut.

from bytes.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.