#futures #tokio #threadpool #io


Alternative tokio thread pool for executing short, I/O-heavy futures efficiently

11 releases

0.2.0-alpha.4 Apr 7, 2020
0.2.0-alpha.3 Oct 1, 2019
0.2.0-alpha.2 Sep 23, 2019
0.1.6 Jun 6, 2019
0.1.3 Jul 20, 2018

#32 in #threadpool

Download history 93/week @ 2021-04-06 110/week @ 2021-04-13 105/week @ 2021-04-20 53/week @ 2021-04-27 89/week @ 2021-05-04 66/week @ 2021-05-11 79/week @ 2021-05-18 63/week @ 2021-05-25 51/week @ 2021-06-01 57/week @ 2021-06-08 47/week @ 2021-06-15 51/week @ 2021-06-22 59/week @ 2021-06-29 47/week @ 2021-07-06 55/week @ 2021-07-13 57/week @ 2021-07-20

376 downloads per month
Used in tokio-reactor


426 lines



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

It is no longer necessary following the scheduler improvements in tokio 0.2.0-alpha.7, which handle concurrent I/O on many sockets much better than the old scheduler did. Tokio 0.2 also does not allow the same hooks to provide a custom scheduler, so even if it were necessary, updating tokio-io-pool to work as "transparently" as it did with tokio 0.1 would be difficult. For that reason, this project has been discontinued. If you find an issue with tokio's performance, file it as a tokio bug :)


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.


use tokio::prelude::*;
use tokio::io::AsyncReadExt;
use tokio::net::TcpListener;

fn main() {
    let server = async move {
        // Bind the server's socket.
        let mut listener = TcpListener::bind("").await.expect("unable to bind TCP listener");
        // Pull out a stream of sockets for incoming connections
        loop {
            let (sock, _) = listener.accept().await.expect("acccept failed");
            tokio::spawn(async move {
                let mut sock = sock;
                let (mut reader, mut writer) = sock.split();
                let bytes_copied = reader.copy(&mut writer);
                let n = bytes_copied.await.expect("I/O error");
                println!("wrote {} bytes", n);

    // Start the Tokio runtime


~35K SLoC