purpleprotocol / mimalloc_rust

A Rust wrapper over Microsoft's MiMalloc memory allocator

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Release libmimalloc-sys changes in 3a845029?

nc7s opened this issue · comments

3a84502 changed quite a few enum values, I wonder why that wasn't released.

I'm packaging the mimalloc and libmimalloc-sys crates on Debian, patching -sys to use already packaged libmimalloc-dev 2.0.6. It failed extended::tests::runtime_option_page_reset as it used an old enum value.

We definitely shouldn't be adding tests for the experimental enum values -- arguably they shouldn't be exposed at all.

(I should keep a closer eye on this repo...)

Without this happening, I'll happily package it and it'll silently fail later...

People shouldn't use the experimental constants if they aren't using a fixed/pinned version of mimalloc.

There's only one version of libmimalloc-dev in one Debian dist (unstable/testing/etc.) at a time, so, yeah, basically pinned. We used it instead of the bundled mimalloc.

No, that's not really pinned. I mostly mean statically linked against the bundled version. E.g. Debian might update mimalloc without rebuilding the code using it (which is the issue here).

I wonder if we should put these (and any other incomplete API that can't safely be used by code which dynamically links mimalloc) behind some kind of experimental feature that people need to explicitly enable. Then, Debian should just not package a version with such a feature enabled.

If you mean reverse deps aren't updated along with mimalloc itself, that's a problem, but not a big one - maintainers will handle that.

Currently I have marked the extended.rs tests flaky. Or experimental features could be patched out?