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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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
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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.