SlotPoller

A bounded futures collection with speed, task fairness, and memory efficiency.

Motivation

This crate implements polling of a group of futures, similar to FuturesUnordered from the futures crate.

It uses a fixed number of slots, hence the name. The slots can live either on the stack or on the heap, and the former case was a main motive for developing this crate. However, the resulting library turned out to be more performant than futures and many other crates in the Rust ecosystem.

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, so even using HeapSlots will be very friendly to your allocator.

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.

Comparison to other crates

Notable features of this crate include:

Top-tier performance based on latency and other benchmarks
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.

License