Summary:
This crate provides the core features of the commonly known `Bytes` crate:
zero-copy slicing and cloning, while also supports mmap-backed buffers.
The main motivation is to replace `Mmap` in `indexedlog`. That has multiple
benefits:
- Handles 0-sized mmap more cleanly.
- Handles clones more cleanly.
- Gain the flexibility to zero-copy data without lifetime / reference.
- Gain the flexibility to switch to non-mmap data.
The `bytes::Bytes` crate does not yet support mmap buffers as of its latest
release (0.5.4).
Implementation wise, `minibytes::Bytes` uses `Option<Arc<dyn Trait>>` for the
"trait object". This makes implementing the mmap storage just one line.
`bytes 0.5.4` re-invents the "trait object" manually using unsafe code. It requires
about 50 lines to implement the mmap storage (in D19756122).
Reviewed By: xavierd
Differential Revision: D19770856
fbshipit-source-id: 8cfa7052a18ac2e0cd6348b77d5e2a4acc61195c
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h> or use cpython) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths
entrirely in native code, we'll want to limit our dependency on Python, which is
why this barrier exists.
See also hgext/extlib/README.md, mercurial/cext/README.mb.
How do I choose between lib and extlib (and cext)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib (if it's only used by extensions) or
mercurial/cext (if it's used by extensions or core).
108f1c947a