6 releases

new 0.3.3 Dec 4, 2024
0.3.2 Dec 3, 2024
0.3.1 Sep 5, 2024
0.3.0 Aug 21, 2024
0.2.1 Aug 14, 2024

#179 in Memory management

Download history 186/week @ 2024-08-17 37/week @ 2024-08-24 155/week @ 2024-08-31 32/week @ 2024-09-07 29/week @ 2024-09-14 16/week @ 2024-09-21 36/week @ 2024-09-28 9/week @ 2024-10-05 19/week @ 2024-10-12 6/week @ 2024-10-19 2/week @ 2024-10-26 14/week @ 2024-11-02 1/week @ 2024-11-09 7/week @ 2024-11-16 9/week @ 2024-11-23 277/week @ 2024-11-30

299 downloads per month
Used in 5 crates (4 directly)

MIT/Apache

110KB
3K SLoC

buffet

buffet is designed to memmap a big chunk of memory and then, well, hand out reference-counted (non-thread-safe) pieces of it. It was faster than stack allocation in some benchmark I did a while ago.

Also, it's compatible with io_uring in that you can give ownership of one of the pieces to a read/write operation and nobody else is able to use it until that operation is done, which is really neat.

There's a bunch of splitting operations that try to maintain reference count and the general "one mutable reference XOR multiple read-only references" vibe of the whole endeavor.

I'm not honestly convinced buffet is the optimal way to go about this, but it works for now, it's io_uring and fallback-codepath friendly... ah well.

Dependencies

~6–15MB
~188K SLoC