Talk Description:

The session will be a deep dive into the internals of how the Tokio crate implements its multi-threaded scheduler using Rust’s low level primitives, the reactor using OS syscalls and the task state machine using atomic state transitions. It will cover my learnings from writing a multi -threaded asynchronous runtime using the MIO crate (the same crate that tokio uses).

Following is the link to my repository -
https://github.com/abh1nav10/async-rt

The structure of the talk looks like the following -

Beginning

A slide with the benchmarks comparing a fairly straightforward asynchronous HTTP server implemented with hyper and powered by the runtime that I built with three different implementations of the server--
(1) An HTTP server that runs on a single thread and is blocking.
(2) An HTTP server that spawns one thread per connection.
(3) An HTTP server implemented with hyper powered by the TOKIO runtime.

That will help us understand the importance of asynchrony.

Following is the result of the benchmark -

• The benchmark was carried out with wrk with the following inputs-
  wrk -t4 -c1000 --latency
• Ran on ArchLinux on WSL2.

Introduction to Rust’s async infrastructure

This is where I shall talk about how the async infrastructure of Rust has been designed namely futures, wakers, pinning, the async await keywords, tasks and how the runtime makes it all work.

Reactors

Talk about Reactors and about OS syscalls namely epoll, and how the MIO crate exposes a simple API wrapping those syscalls. Talk about how I have used it in the implementation to make two things happen-

• Make the worker threads park themselves when there is no work to do and make the tasks unpark the worker thread when the future is ready to be polled. That prevents us from wasting power by spinning unnecessarily when there is no work.

• How we register our interest on being notified when lets say a socket becomes readable or writable with the registry. This enables true asyncrony as our worker threads never have to block on those events. Only the reactor thread parks itself and gets woken up by the OS when events are received. Since the reactor thread has a mapping of Tokens to Wakers of the tasks that were waiting for that event, it simply wakes those wakers and the task is pushed back into the queue from where the worker threads poll them again.

State transitions

Talk about the lifecycle of a task and how I use atomic operations in my implementation to enable those transitions. Talk about the risk of double frees and memory leaks and how I avoid them. This is where I will touch a little on atomics in Rust.

Scaling

Talk about the areas where the runtime can be optimized. The talk ends here.

TAKEWAY:

The session will help programmers built a thorough mental model of Async Rust so that they can picture the model while writing code thereby writing better code as a consequence of it and debug in a more efficient way.
The session will also teach programmers about low level concurrency in Rust and the tools that it provides to achieve it.

AUDIENCE :

The session is targeting an audience of developers who use Rust for systems programming, want to dive into the weeds of Async Rust and want to understand the tools it provides to achieve low latency and high throughput concurrency and parallelism.

BIO:

I am a student pursuing my Bachelors in Mathematics (Hons.) from Hansraj College, University of Delhi. I picked up systems programming on my own and have since then been spending a large portion of my time every day diving into the details of memory models, concurrency and parallelism and the Rust programming language, its type system and the infrastructure around it.