4 releases

0.3.1 Sep 5, 2024
0.3.0 Aug 21, 2024
0.2.1 Aug 14, 2024
0.2.0 Aug 14, 2024

#107 in Memory management

Download history 221/week @ 2024-08-09 191/week @ 2024-08-16 44/week @ 2024-08-23 125/week @ 2024-08-30 67/week @ 2024-09-06 27/week @ 2024-09-13 18/week @ 2024-09-20 31/week @ 2024-09-27 9/week @ 2024-10-04

87 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
~183K SLoC