Messages in this thread | | | Date | Fri, 2 Apr 2004 10:04:19 +0100 (BST) | From | Ben Mansell <> | Subject | Re: epoll reporting events when it hasn't been asked to |
| |
On Thu, 1 Apr 2004, Steven Dake wrote:
> 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.
Is there any difference, speed-wise, between turning off all events to listen to with EPOLL_MOD, and removing the file descriptor with EPOLL_DEL? I had vaguely assumed that the former would be faster (especially if you might later want to resume listening for events), although that was just a guess.
Ben - 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/
| |