From a39574cfec731432bf9e4740cc3c62f904acc962 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Sat, 18 Mar 2017 00:41:14 +0000 Subject: doc: design_notes: we do not use EPOLLEXCLUSIVE And clarify that we only have one thread by default. Since EPOLLEXCLUSIVE seems to have gotten some more press, I guess we should emphasize our design does not rely on it. --- Documentation/design_notes.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/design_notes.txt b/Documentation/design_notes.txt index 308faa6..68d31bc 100644 --- a/Documentation/design_notes.txt +++ b/Documentation/design_notes.txt @@ -17,9 +17,12 @@ socket we have inside the kernel. Each listen queue has a dedicated thread pool running _blocking_ accept(2) (or accept4(2)) syscall in a loop. We use dedicated threads and blocking accept to benefit from "wake-one" behavior in the Linux -kernel. By default, this thread pool only has thread per-process, doing +kernel. By default, this thread pool only has one thread per-process, doing nothing but accepting sockets and injecting into to the event queue -(used by epoll or kqueue). +(used by epoll or kqueue) so a worker thread pool can pick them up. + +This design makes EPOLLEXCLUSIVE in Linux 4.5+ unnecessary to us, +our listen sockets are never registered with epoll or kqueue. worker thread pool ------------------ @@ -38,7 +41,7 @@ allows us to guarantee exclusive access to a client socket without additional locks managed in userspace. Idle threads will sit performing epoll_wait(2) (or kevent(2)) -indefinitely until a socket is reported as "ready" by the kernel. +indefinitely until a client socket is reported as "ready" by the kernel. queue flow ---------- -- cgit v1.2.3-24-ge0c7