[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Ticket #70 - Support for epoll's EPOLLRDHUP

On Sun, Dec 22, 2013 at 8:51 PM, Diego Giagio <diego@xxxxxxxxxx> 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

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.

To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.