Mimalloc has a pretty rich API, with a bunch of handy functions. libmimalloc-sys only exposes a pretty small set of them.
Concretely, I have uses for the local heap API, but ideally libmimalloc-sys would most of mimalloc's public API, as it is one of the most rich and fully featured apis of any allocator, and I've missed various functions from it on many occasions.
My plan here is to write manual bindings, and add tests verifying that they match the equivalent C code using ctest. This allows for good documentation, good IDE support, and is a very common way of doing this (libc, git2-rs, openssl-sys, ...).
The obvious other option is bindgen. I don't think it's a good choice for this, and wrote about it below*. That said, I have a lot of experience with it, and could make it work if you'd vastly prefer that.
Anyway, I can submit a PR for this, and would be willing to help maintain it going forward (unless that's not desirable) I know it's a large increase in API surface. That said, I'd really rather not introduce yet another mimalloc crate, and would prefer to just make yours better/more fully featured.
Anyway, I have part of this done already, but want to test on win/lin, so I probably will have a PR up soon after I test on windows and such.
Footnote: why not bindgen
For context, I'm one of the maintainers of libsqlite3-sys, which according to https://crates.io/crates/bindgen/reverse_dependencies is the largest user on crates.io of bindgen as a buildtime library. My feelings on it are complex, but to summarize: it's massively convenient, but for anything nontrivial it ends up getting in the way:
It adds a bunch of build complexity, drawbacks, slow/difficult compiles, guaranteed poor IDE integration, hard/impossible to add documentation, ...
The workarounds for these problems all have their own drawbacks (when they exist -- the IDE/docs issue are unavoidable).
In particular the main work around for the worst of the issues (pregenerating bindings so that people don't need to link against clang) makes the version support situation much more complex.
It makes building with most non-cargo things like bazel/buck and such harder, although probably it's already tricky for libmimalloc-sys, as it has a nontrivial build.rs.
(That said there are a lot of good cases to use it -- it's good in some ways for libsqlite3-sys's case of "supporting just about any imaginable sqlite version/build/config" but... I really don't recomend being in that case).
Mimalloc has a pretty rich API, with a bunch of handy functions.
libmimalloc-sysonly exposes a pretty small set of them.Concretely, I have uses for the local heap API, but ideally
libmimalloc-syswould most ofmimalloc's public API, as it is one of the most rich and fully featured apis of any allocator, and I've missed various functions from it on many occasions.My plan here is to write manual bindings, and add tests verifying that they match the equivalent C code using
ctest. This allows for good documentation, good IDE support, and is a very common way of doing this (libc,git2-rs,openssl-sys, ...).The obvious other option is
bindgen. I don't think it's a good choice for this, and wrote about it below*. That said, I have a lot of experience with it, and could make it work if you'd vastly prefer that.Anyway, I can submit a PR for this, and would be willing to help maintain it going forward (unless that's not desirable) I know it's a large increase in API surface. That said, I'd really rather not introduce yet another mimalloc crate, and would prefer to just make yours better/more fully featured.
Anyway, I have part of this done already, but want to test on win/lin, so I probably will have a PR up soon after I test on windows and such.
Footnote: why not bindgen
For context, I'm one of the maintainers of libsqlite3-sys, which according to https://crates.io/crates/bindgen/reverse_dependencies is the largest user on crates.io of bindgen as a buildtime library. My feelings on it are complex, but to summarize: it's massively convenient, but for anything nontrivial it ends up getting in the way:
It adds a bunch of build complexity, drawbacks, slow/difficult compiles, guaranteed poor IDE integration, hard/impossible to add documentation, ...
The workarounds for these problems all have their own drawbacks (when they exist -- the IDE/docs issue are unavoidable).
It makes building with most non-cargo things like bazel/buck and such harder, although probably it's already tricky for libmimalloc-sys, as it has a nontrivial build.rs.
(That said there are a lot of good cases to use it -- it's good in some ways for libsqlite3-sys's case of "supporting just about any imaginable sqlite version/build/config" but... I really don't recomend being in that case).