4 ms·
My experience of epoll is that it's for single process, single thread network I/O mostly. If you want multithreaded network server use SO_REUSEPORT, and one epo
by adontz 4y ago
My experience of epoll is that it's for single process, single thread network I/O mostly. If you want multithreaded network server use SO_REUSEPORT, and one epoll per thread. Everything else is either broken, overcomplicated or slow.
- wbl 4y agoOr use IOCP on Windows or kqueue on FreeBSD. IOCP is particularly interesting as it will interact with the scheduler and release more threads if ones get blocked, trying to right-size CPU usage.
- mritun 4y agoThis is the correct answer (on Linux) and the article dismisses it after lightly touching on it’s correctness. In a multi-threaded environment someone needs to pay the cost of synchronization if the entire event-queue is loadbalanced. If you don’t want the events to be trivially load-balanced and want the events from one fd to be delivered to a single worker, then it’s way better to use SO_REUSEPORT and get it right from the get go. Expecting kernel to solve a problem of user-space’s making is asking for trouble - can be done, but the edge cases will sink your project!
- naasking 4y ago> Expecting kernel to solve a problem of user-space’s making is asking for trouble These are problems the kernel has introduced. I'm not sure you've read article carefully enough.
- jbluepolarbear 4y agoThis is what I was thinking reading this. Why are they reading the the same buffer in 2 threads. This problem will always happen if reading the same buffer in 2 threads.
- naasking 4y agoThey are not. This happens for any fd, like a socket waiting for a connection.
- throwaway858 4y agoThe Go runtime (and GHC runtime) use epoll from multiple threads and don't use SO_REUSEPORT and are highly efficient. I do believe that they use one epoll per thread.
- scaramanga 4y agoAnother correct solution which avoids the issue which is entirely of userspaces creation :)