Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpawnError should support alloc failures #2928

Open
jasta opened this issue Feb 26, 2025 · 0 comments
Open

SpawnError should support alloc failures #2928

jasta opened this issue Feb 26, 2025 · 0 comments

Comments

@jasta
Copy link

jasta commented Feb 26, 2025

SpawnError currently only has the notion that spawning can fail because the executor is shutdown, however eventually when allocator-api is stabilized we will want to be able to fail to spawn due to out-of-memory conditions. I propose we add SpawnError::alloc_error() or maybe even generalized to SpawnError::capacity_exceeded() to accomodate for this future case.

For some context, I'm interested in using FuturesUnordered as a means of supporting spawn-style async programming for common libraries that may be used in either embassy or tokio runtimes. For tokio this is no problem and FuturesUnordered will work as-is, but for the embassy use cases I anticipate that customers will want to be able to provide their own fixed size pre-allocated storage for the Arc's and be able to therefore achieve a kind of upper bound on the number of futures supported. Imagine we had like a CoAP or HTTP server and wanted to only be able to support up to 8 simultaneously client connections. This could be done using FuturesUnordered with a crude slab allocator that can create up to 8 Box<dyn Future> instances, and now by using Arc::try_new_in and passing the resulting AllocError's back we'd be able to do all this gracefully at runtime without hacks or compromises for the memory constrained cases.

Also note that I'm currently exploring forking FuturesUnordered in order to add support for allocator-api to show that this can work in practice, I will be able to publish that work shortly but the intention is not to put that on crates.io, but just to demonstrate what will be possible once we have allocator-api.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant