The trick isn&#x27;t &quot;use a bunch of threads&quot; but to have each cpu do a separate task (N1 threads for accept, N2 threads for read, N3 threads for write, N4 threads for close, etc) and using a separate keventfd&#x2F;epollfd for each thread.<p>The tasks can still use blocking calls (or nonblocking, as they like), which makes it different than strategy 1 or 2. It shards by task which is different than 3, or 4. Completion-notification is not explicit. It is clearly different than 5 or 6.<p>I think you should read it carefully. Popular webservers like nginx and varnish do not implement this method, so I do not believe it is common, and there are a few neat features of this method:<p>1. Tasks will usually fit into cache. If the kernel hotpaths to IP they usually won&#x27;t fall out of cache either. This can produce 100x or even 1000x speed improvements for complex tasks.<p>2. It may be easy to convert an existing program to this design than to replace everything with nonblocking IO, or to move into kernel space, or to attach to a userland TCP stack.<p>These things are important if you want to write faster servers.