Skip to content

Use epoll instead of select on linux#32

Open
ardeujho wants to merge 2 commits intorussellallen:masterfrom
ardeujho:use_epoll
Open

Use epoll instead of select on linux#32
ardeujho wants to merge 2 commits intorussellallen:masterfrom
ardeujho:use_epoll

Conversation

@ardeujho
Copy link
Copy Markdown

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.

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.
@ardeujho
Copy link
Copy Markdown
Author

For normal desktop use the number of files opened on average is low. You can see this by inspecting scheduler selectVec countHowMany: [ |:x| x isNotNil]. It's about 5 on my system.

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.
@ardeujho
Copy link
Copy Markdown
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants