libev epoll and EPOLLRDHUP

[fatmck]

After you accept a new connection, you must use ev_io_init() and 
ev_io_start() to start waiting read event on the new fd. By doing this, 
you can get a read event when the connection goes down.


于 2013年06月13日 14:24, Chaliha, Sayan 写道:
> Hi Marc,
>
> 1. I'm using Ubuntu 12.04 LTS (bare-bones kernel and very few modules). uname -a: Linux ATCA-7311 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> 2. Here's my observation:
> 	a. I have a transparent HTTP proxy server
> 	b. The proxy is heavily loaded with connections (around 3 Gbps of data)
> 	c. On any side  of the proxy if a client closes a connection, I don't get a read (or write) event for the last connection that went down. That event 	    comes only when a new connection is established. Off late testers are reporting that more than ten or eleven connection close events are being 	    missed with epoll enabled.
> 	d. With poll it works absolutely fine: For every connection that is closed, I immediately get an event.
>
> Thank you for your help!
>
> --
> Warm regards,
> Sayan.
>
>
> -----Original Message-----
> From: Marc Lehmann [mailto:schmorp at schmorp.de]
> Sent: Thursday, June 13, 2013 5:01 AM
> To: Chaliha, Sayan
> Cc: libev at lists.schmorp.de
> Subject: Re: libev epoll and EPOLLRDHUP
>
> On Wed, Jun 12, 2013 at 05:19:31PM +0530, "Chaliha, Sayan" <sayan.chaliha at in.verizon.com> wrote:
>> I'd like a notification from libev when a TCP connection goes down.
>> This works fine with poll backend, but with epoll backend it doesn't.
>> My guess is because EPOLLRDHUP is not being handled. Could I have a
>> patch for this please?
> Hi - this doesn't make much sense: libev already notifies you when a tcp connection goes down (for both read and write watcher depending on which half is closed). It makes no obvious sense for libev to handle EPOLLRDHUP in any way.
>
> Could you describe:
>
> - what behaviour you are seeing.
> - what behaviour do you expect instead.
> - what exactly you think should be changed.
> - how poll differs from epoll in generated signals.
>
> Also, since epoll is extremely badly designed and implemented, maybe you are hitting a bug in your kernel - which kernel version do you see the beahviour with?
>