# SlotPoller
[](https://crates.io/crates/slotpoller)
[](https://www.gnu.org/licenses/license-recommendations.html)
[](https://docs.rs/slotpoller)
A bounded futures collection with speed, task fairness, and memory efficiency.
## Motivation
This crate implements polling of a group of futures. It uses a fixed number of slots, hence the name, and the slots can live on either the stack or the heap.
Stack usage was the main inspiration for developing this crate. However, the resulting library turned out to be more performant than other crates in the Rust ecosystem. And thanks to being bounded, it's very ergonomic for enforcing backpressure throughout an entire codebase.
### Comparison to other crates
Notable features of this crate include:
* Top-tier [performance](performance.md) based on latency benchmarks and benchmarks from [notgull and zetanumbers](https://github.com/zetanumbers/futures-concurrency-benchmark).
* Memory efficiency, including cheap stack allocation.
* Clean and useful API methods.
* Fairness policy that prevents a future from being polled more than once (in the same loop). This ensures that the runtime, other tasks owned by the poller, and other async functions have their chance to make progress.
## Crate API
There are 3 main structs: `StackSlots`, `HeapSlots`, and `SlotPoller`. First you pick one of the memory locations (Stack or Heap), then plug it into the poller.
```
StackSlots HeapSlots
const N: usize capacity: usize
| |
| |
|---------|-----------|
|
\|/
SlotPoller
```
This lets us support both memory locations using the same API. In either case, the memory is allocated up front, meaning that once the poller is created, no more memory will be used by this library.
Note that *StackSlots* is forced to abort the program if a future panics in its destructor. This is required by Rust's drop guarantee for pinned data.
### Why are the collections bounded?
Bounded queues are safer (they can't blow up with a billion elements) and offer better performance. A bounded queue reduces allocations, and it means that your program focuses on finishing the work it has already started, before moving on to new tasks. This is improves both end-user latency and cache efficiency, especially for smaller buffer sizes.
This crate also follows the UNIX philosophy, so we aren't going to add new features "just because." If you really need an unbounded group of futures, use a different crate.
## License
Apache 2.0. See the license file.