Menu
▾
▴
#70 Support for EPOLLRDHUP
The EPOLLRDHUP flag can be useful to listen for. This event fires when the remote side calls close() on the socket that is being polled for. This event can often help you handle situations where a service is overloaded. For example, if your service has slowed down to the point where clients are aborting their connections before you can process them, listening for RDHUP events lets you recognize that the client has abandon their request and avoid processing it.
Facebook is putting a $200 bounty on this feature via bountysource: https://www.bountysource.com/issues/1328018
Patch to add support for EPOLLRDHUP. Since Linux 2.6.17 epoll is able to report about peer half-closed connection using special EPOLLRDHUP flag on a read event. This patch is backwards compatible with older kernels. All regression tests were OK.
Thanks for the patch. Do you have an example program that makes use of this patch. One question is how the user makes use of the RDHUP event. The user should be able to tell that a RDHUP event is pending and take action on it. I'm not sure how one does that in this patch.
Imagine for example, you're writing an HTTP 1.0 server (for simplicity):
(1) If the user has sent you a GET request, called close() but you haven't read anything yet, you should be able to see that the socket has an RDHUP pending and close it without bothering to read the request
(2) If you read the GET request by the user closes the socket before you reply, you should be able to see the RDHUP request without having to add the READ flag to the socket.
You might also want to post to the mailing list, that may be more active.
Ben, this patch triggers the EV_READ|EV_WRITE flags when an RDHUP is received (just like when an error occurs or the other end is closed), but if I understand correctly this isn't enough for your scenarios, specially (1).
To be able to know when an RDHUP occurs we probably need another EV_something added to the events flags. Currently we only have: EV_TIMEOUT, EV_READ, EV_WRITE, EV_SIGNAL, EV_PERSIST and EV_ET. None of these can be used to signal what we want.
I did some research and I found that nginx added support for EPOLLRDHUP by adding a 'pending_eof' flag, allowing it to discard those connections as fast as possible[1].
I will send a message to the mailing list asking for some opinions regarding this, specially on the possibility of adding a new flag like EV_EOF or something.
[1] http://trac.nginx.org/nginx/ticket/320
Status implementation. A revised epoll patch for this feature has merged into Libevent, and it seems to work okay. Nice job, Diego! The kqueue patch for similar functionality is still a work in progress, if I understand correctly. But since this ticket is only about getting it done with epoll, I'm happy to call it "done" if others agree.
Closing as implemented. There's more work to do on the general topic, but the basic requirement is done. Thanks!