You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 toSpawnError::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.
The text was updated successfully, but these errors were encountered: