2009-01-29 15:44:49

by Howard Chu

[permalink] [raw]
Subject: epoll optimizations

Something I tripped over recently, that might be nice to change... HANGUP
events are always reported, and apparently can't be turned off. In
level-triggered mode, if your event loop treats Hangups as lower priority than
read/write events, an outstanding Hangup will continue to be signaled every
time you call epoll_wait() until it's finally disposed of. It would be nice if
Hangups were always oneshot events, regardless of whether the FD was
configured level, edge, or oneshot. Certainly we know that the *cause* of a
Hangup can only happen once on any descriptor, so it makes no sense for it to
be reported more than once.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/


2009-01-30 00:10:31

by Davide Libenzi

[permalink] [raw]
Subject: Re: epoll optimizations

On Thu, 29 Jan 2009, Howard Chu wrote:

> Something I tripped over recently, that might be nice to change... HANGUP
> events are always reported, and apparently can't be turned off. In
> level-triggered mode, if your event loop treats Hangups as lower priority than
> read/write events, an outstanding Hangup will continue to be signaled every
> time you call epoll_wait() until it's finally disposed of. It would be nice if
> Hangups were always oneshot events, regardless of whether the FD was
> configured level, edge, or oneshot. Certainly we know that the *cause* of a
> Hangup can only happen once on any descriptor, so it makes no sense for it to
> be reported more than once.

Since epoll does not have the concept of priority, that means that you
have to scan the whole array of returned events anyway. It is sufficient
that when you notice a POLLHUP, you do a quick handling with a simple
epoll_ctl(DEL), append the fd to a lazy-handling queue, and take care of
it when time comes.



- Davide