4 ms·
> All of my I/O got pushed through one thread (with tokio) In all my use of Tokio in the last few years, I never heard of such a thing. In tokio::fs::File [1]
by ReactiveJelly 3y ago
> All of my I/O got pushed through one thread (with tokio)
In all my use of Tokio in the last few years, I never heard of such a thing.
In tokio::fs::File [1] it calls spawn_mandatory_blocking to do file writes, I assume this is similar to spawn_blocking [2] which sends a task to Tokio's blocking thread pool. That thread pool is supposed to max out at 512 blocking threads [3], unrelated to CPU core count.
Tokio's TcpStream appears to be built on mio's TcpStream. I didn't dig deep into the code for this, but it doesn't just call spawn_blocking, and I'm assuming on Unix it ultimately registers the socket with epoll or equivalent, so it never blocks a thread to do socket reads or writes.
Could you share more about your application?
[1] https://docs.rs/tokio/latest/src/tokio/fs/file.rs.html#682 https://docs.rs/tokio/latest/src/tokio/fs/file.rs.html#682
[2] https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.html https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...
[3] https://docs.rs/tokio/latest/tokio/runtime/struct.Builder.html#method.max_blocking_threads https://docs.rs/tokio/latest/tokio/runtime/struct.Builder.ht...
- sargun 3y agoSo, it wasn't actually synchonrizing all of the I/Os onto one thread, but I wasn't getting any parallelism due to the amount of time required to dispatch I/Os. Essentially, my program was highly concurrent, but I wasn't able to get any I/O parallelism because each syscall was pretty cheap, and the cost of dispatching each I/O was too expensive.