Not really. epoll only makes sense for file descriptors which would normally exhibit blocking behavior on read/write, like pipes and sockets. Normal file descriptors will always either return a result or end-of-file more or less immediately, so epoll wouldn’t do anything useful for them.
It is thread-safe, but there isn’t much documentation that explicitly states that. See here BTW, you can also have multiple threads waiting on a single epoll_fd, but in that case it can get a bit tricky. (I.e. you might want to use edge-triggered EPOLLET or oneshot mode EPOLLONESHOT. See here.)
In Windows, async operations are done by file operation, not by descriptor. There are several ways to wait on file operations to complete asynchronously. For example, if you want to know when data is available on a network socket, issue an async read request on the socket and when it completes, the data was available … Read more
Events is one of the paradigms to achieve asynchronous execution. But not all asynchronous systems use events. That is about semantic meaning of these two – one is super-entity of another. epoll and aio use different metaphors: epoll is a blocking operation (epoll_wait()) – you block the thread until some event happens and then you … Read more
This makes sense once you look for ep_find. I only spent a few minutes with it and I see ep_find is only called by epoll_ctl. So indeed, when you add the descriptors (EPOLL_CTL_ADD) that costly operation is performed. BUT when doing the real work (epoll_wait) it isn’t. You only add the descriptors in the beginning. … Read more
The answer is epoll if you’re using Linux, kqueue if you’re using FreeBSD or Mac OS X, and i/o completion ports if you’re on Windows. Some additional things you’ll (almost certainly) want to research are: Load balancing techniques Multi-threaded networking Database architecture Perfect hash tables Additionally, it is important to note that UDP does not … Read more
When an FD becomes read or write ready, you might not necessarily want to read (or write) all the data immediately. Level-triggered epoll will keep nagging you as long as the FD remains ready, whereas edge-triggered won’t bother you again until the next time you get an EAGAIN (so it’s more complicated to code around, … Read more
There’s a lot of misinformation about this, but the real reason is this: A typical server might be dealing with, say, 200 connections. It will service every connection that needs to have data written or read and then it will need to wait until there’s more work to do. While it’s waiting, it needs to … Read more
Threadpool does not really fit into the same category as poll and epoll, so I will assume you are referring to threadpool as in “threadpool to handle many connections with one thread per connection”. Pros and cons threadpool Reasonably efficient for small and medium concurrency, can even outperform other techniques. Makes use of multiple cores. … Read more