This crate provides a thread pool for executing short, I/O-heavy futures efficiently.

The standard Runtime provided by tokio uses a thread-pool to allow concurrent execution of compute-heavy futures. However, its work-stealing makes it so that futures may be executed on different threads to where their reactor are running, which results in unnecessary synchronization, and thus lowers the achievable throughput. While this trade-off works well for many asynchronous applications, since it spreads load more evenly, it is not a great fit for high-performance I/O bound applications where the cost of synchronizing threads is high. This can happen, for example, if your application performs frequent but small I/O operations.

This crate provides an alternative implementation of a futures-based thread pool. It spawns a pool of threads that each runs a tokio::runtime::current_thread::Runtime (and thus each have an I/O reactor of their own), and spawns futures onto the pool by assigning the future to threads round-robin. Once a future has been spawned onto a thread, it, and any child futures it may produce through tokio::spawn , remain under the control of that same thread.

In general, you should use tokio-io-pool only if you perform a lot of very short I/O operations on many futures, and find that you are bottlenecked by work-stealing or reactor notifications with the regular tokio runtime. If you are unsure what to use, start with the tokio runtime.

Be aware that this pool does not support the blocking function since it is not supported by the underlying current_thread::Runtime . Hopefully this will be rectified down the line.

There is some discussion around trying to merge this pool into tokio proper; that effort is tracked in tokio-rs/tokio#486.