Redis: One Thread, Many Clients

The board behind this lesson. Sits under the project lesson Build Your Own Redis - From Scratch, and hands off to Keys That Die (Expiry).

Before you start. This series builds a small copy of Redis, a program that stores keys and values in memory and answers other programs over the network. So far the copy can take the raw characters arriving on a network connection (a socket) and split them into commands, using Redis’s own message format, RESP (Redis 02: RESP, The Wire Protocol). It also keeps every key in one shared table, and the last lesson found a crack in it: two things touching that table at once corrupt it (Redis: The Map (SET / GET / DEL)).

The idea in 30 seconds

A worker that can only do one thing at a time is a thread, and blocking on one quiet connection freezes it for everyone else it was serving.
Hiring a thread per connection works for a while, then buckles: idle workers cost real machine time just standing around.
epoll asks the kernel one question, who’s ready, instead of checking every table by hand, so a busy restaurant costs the same as a quiet one.
Every socket has to promise not to freeze the waiter; that promise is called non-blocking.
Knowing a table is ready is not knowing the whole order arrived; sorting that out is still the loop’s job.
One waiter means no two hands ever touch the shared table at once, and it means one enormous order can freeze everyone else’s.

Read the story · Skip to the numbers