Subject: Re: epoll reporting events when it hasn't been asked to
From: Steven Dake <sdake@mvista.com>
Reply-To: sdake@mvista.com
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Ben Mansell <ben@zeus.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.44.0404011125510.2509-100000@bigblue.dev.mdolabs.com>
References: <Pine.LNX.4.44.0404011125510.2509-100000@bigblue.dev.mdolabs.com>
Content-Type: text/plain
Organization: MontaVista Software, Inc.
Message-Id: <1080862174.9534.112.camel@persist.az.mvista.com>
Mime-Version: 1.0
Date: Thu, 01 Apr 2004 16:29:35 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1180
Lines: 32

On Thu, 2004-04-01 at 12:28, Davide Libenzi wrote:
> On Thu, 1 Apr 2004, Ben Mansell wrote:
> 
> > > It is a feature. epoll OR user events with POLLHUP|POLLERR so that even if
> > > the user sets the event mask to zero, it can still know when something
> > > like those abnormal condition happened. Which problem do you see with this?
> > 
> > What should the application do if it gets events that it didn't ask for?
> > If you choose to ignore them, the next time epoll_wait() is called it
> > will return instantly with these same messages, so the app will spin and
> > eat CPU.
> 
> Shouldn't the application handle those exceptional conditions instead of 
> ignoring them?
> 
> 

If an exception occurs (example a socket is disconnected) the socket
should be removed from the fd list.  There is really no point in passing
in an excepted fd.

epoll works just like poll and the expected SUS behavior in this regard.

Thanks
-steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/