Add custom allocator support #98
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for custom allocators. Allows to control memory allocation for tasks by passing an allocator to new
spawn_in,spawn_local_in, andspawn_unchecked_infunctions and corresponding Builder methods hidden under the new feature flags.It adds two different feature flags:
allocator_apifeature.allocator-api2feature.The allocator is stored inline with the task and dropped when the raw task is destroyed.
Some concerns:
I saw this issue, and I understand the doubts about the API stability. However, I'd like to offer a few points to consider:
allocator-api2crate is designed for stable Rust and is already used by major crates (hashbrown, bumpalo, etc.).allocator_apifeature only works on nightly builds, which makes it self-explanatory that it's unstable and that theAPI may change in the future. Alternatively, we could support only
allocator-api2and drop the nightlyallocator_apifeature entirely.Additionally, these changes may require updates to some workflows, such as
smol-rs/.github/.github/workflows/clippy.yml. If this PR is considered for merging, I'll make the required changes.I should mention that I'm not an expert in low-level Rust, so there may be areas in the unsafe code or memory management that could be improved. And even if this PR isn't the right fit for the crate given the instability of allocator API, I hope it can at least serve as a reference for anyone who wants to support custom allocators in their own forks.