search

purpleprotocol / mimalloc_rust

A Rust wrapper over Microsoft's MiMalloc memory allocator
MIT License
481 stars 42 forks source link

Release libmimalloc-sys changes in 3a845029? #84

Closed nc7s closed 8 months ago

nc7s commented 1 year ago

https://github.com/purpleprotocol/mimalloc_rust/commit/3a8450294385d2dd0a54c955caf7faf35d48f71a 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.

thomcc commented 1 year ago

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...)

nc7s commented 1 year ago

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

thomcc commented 1 year ago

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

nc7s commented 1 year ago

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.

thomcc commented 1 year ago

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.

nc7s commented 1 year ago

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?