could epoll totally replace select/poll when it is available?
i am new to sockets and i am learning/reading some epoll materials and codes. My questions is that could epoll totally replace select/poll when epoll is available in system(Linux)?
i think socket programming also should have some paradigms to follow in practice. When i was reading codes, i find some "select" with "epoll":
a server code use select when it deals with blocking socket. I think epoll(LT) behaves just the same as select so it is ok to use epoll to replace all select.
some legacy code use epoll to monitor. After events returns, select is used on corresponding fd to "check" it just before read/write. i am not quite sure the meaning of this "select".
i am confused about these "select" code and hope someone can help.
Select, Poll and epoll are all targeting the same need: To wait until a descriptor is ready for read or write, so then one can process the descriptor (reading from it or writing to it).
epoll is a relative newer implementation and is specific to Linux OS (and therefore, not portable). It has the advantage of returning only the descriptors that are pending without the need to pass all descriptors and check which one caused the system call to return. In many cases, epoll is faster then the select or poll.
Using epoll mixed with select sounds to me like a legacy code that was patched without refactoring the older code. epoll will implement select in a cleaner and faster way (in most cases) and as you mentioned, can work in one of two modes (edge or level ).
There are some complex instances where an epoll descriptor may be nested in another epoll, implementing a type of hierarchy, but I think it is rare and I personally never saw a code implementation of it.