Epoll_wait several threads faster?

I am thinking of epoll based tcp server programming. For best performance, I also want to implement multi-core support. But during my research, the following question arose: Is it faster to call two epoll_wait() -Calls from two different threads, each of which observes its own file descriptors on a dual core kernel? Or is it as fast as calling just one epoll_wait() that keeps track of all file descriptors?

Since the kernel is monitoring file descriptors, I think it doesn't matter how many threads I use for user space calling epoll_wait() ?

+7
source share
2 answers

You can even call epoll_wait on multiple threads at the same time for the same epoll_fd, as long as you use the red (EPOLLET) mode (and be careful with synchronization). Using this approach, you can get real performance benefits on multi-core machines over the single-threaded epoll event loop.

I actually took performance measurements a while ago, see my blog post about the results:

+10
source

I suspect that you are correct that the performance of epoll itself is no different in the two scenarios you mentioned. What may matter, OTOH, is that with a loop of events in each thread, you do not need to switch the context to a separate worker thread to handle the connection. This, for example, is how nginx works, see, for example, http://www.aosabook.org/en/nginx.html .

0
source

All Articles