On Sun, Dec 22, 2013 at 8:51 PM, Diego Giagio <di...@giagio.com> wrote: > Hi, > > I'm working on a patch to add support for epoll's EPOLLRDHUP flag to > libevent. This is a feature requested on ticket #70[1]. > > The first version of the patch is attached to that issue and it already makes > it possible to identify when a client prematurely closes the other end of the > socket. Unfortunately with the current EV_* flags it's not possible to tell > the programmer that this happened so he can act accordingly without > recv()'ing all the pending data. > > I've done some research and I found out that nginx added a flag named > 'pending_eof' when it detected EPOLLRDHUP, making possible to close that > socket as fast as possible without reading the pending data.[2] > > I would like to ask some opinions on how we can add support for this kind of > feature on libevent? My suggestion is to add a new flag, probably named > EV_EOF, so the programmer can act accordingly. From what I've seen, it seems > that kqueue also have a mechanism for detecting such premature closes. I can > also add support for kqueue if necessary.
A key concern here is getting the API right so that code written to be aware of EV_EOF will not break on select() or poll() backends. One way to try to get it right would be to look at the "enum event_method_feature" logic for event backends. A backend can advertise one or more optional features, and "EV_FEATURE_EARLY_EOF" could be one of them. (I don't want to call the feature simply "EV_FEATURE_EOF", because the issue isn't "EOF detection" but rather "detection of EOF before reading all the data".) As for how to implement it: Here's a very simple way, though I don't know whether it would be acceptable. I'd suggest treating EV_EOF as a subflag of EV_READ. In other words, you couldn't make an event with EV_EOF unless it also has EV_READ. When listening for EPOLLIN in the backend, you could also listen for EPOLLRDHUP unconditionally, and report EPOLLRDHUP as EV_READ|EV_EOF. A slightly trickier way would be to make EV_EOF a full-fledged flag of its own. This would take a lot more work in and around evmap.c, and would have a higher risk of weird bugs. Whatever option you pick, it would be critical to make sure that you can actually document and use it in a backend-neutral way. That is, it needs to be possible to explain what EV_EOF means in a way that lets people write correct code that works just fine no matter whether the backend is epoll or select. I hope this helps! If you've got any more ideas or questions, just ask. One idea that I support 110% is to solicit feedback on the API patch before writing any implementation code. That way, if the API turns out to be wrong, there isn't so much throwaway work inthe code. peace, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
