Use epoll instead of select on linux #32
Conversation
This removes the use of the select system call for I/O and uses epoll on Linux systems. This removes the limit of 1024 open files that select has and provides better performance.
|
For normal desktop use the number of files opened on average is low. You can see this by inspecting It becomes problematic when writing socket servers. I'm developing a server which has a large number of inactive connections that are fed data sporadically. This ups the count past 1024 on my tests. Using kqueue on Mac OS X would be a good idea and I think should be extended to do this by someone who has access to a Mac. |
epoll doesn't work on regular files. Calls to epoll_ctl return an error of EPERM. I work around this by detecting this case and keeping track of those file descriptors (using an fd_set). These are manually added to the result of a select call as if they were valid to read/write. A longer term solution would be to call 'select' on these file descriptors. Even better might be to move to using asynchronous IO functions (AIO or linux equivalent) on regular files but this is only compatible with epoll on later Linux versions. This needs investigating. Another possibility is using OS threads for i/o.
|
I've updated the branch to work around the fact that epoll doesn't work on regular files. Self doesn't seem to use async i/o for files anyway so it's not really an issue in practice but it's good to handle the case gracefully. Moving to an async i/o system might be a worthwhile future update. |
This removes the use of the select system call for I/O and
uses epoll on Linux systems. This removes the limit of 1024
open files that select has and provides better performance.