Re: Is POLLHUP an input-only or bidirectional condition? (was: epoll reporting events when it hasn't been asked to)

Davide Libenzi
2004-04-03T21:44:08Z

On Fri, 2 Apr 2004, Jamie Lokier wrote:

> None of select, poll or epoll allow a program to ignore POLLERR while
> checking POLLIN or POLLOUT. So at least epoll is consistent with the
> other two.
>
> It is possible to ignore POLLHUP conditions with select(), but not
> poll() or epoll. For sockets at least, POLLHUP should indicate the
> socket is fully closed, so that reading and writing will both fail.
> Thus it makes sense that POLLHUP is not ignorable, although curiously
> select() only treats POLLHUP as an _input_ condition, so it won't wake
> something that's waiting only for output readiness. poll() will
> always wake even if you're only waiting for POLLOUT.
>
> POLLERR is set by UDP sockets with a pending error condition, and that
> will be reported whether you read or write to the socket (except in
> some perverse conditions where MSG_MORE has been used - then app state
> machines could get confused). So it's appropriate for a POLLIN or
> POLLOUT waiter to be woken when there's a POLLERR condition.
>
> Summary: epoll is consistent with poll(). I'm not sure why poll() and
> select() treat POLLHUP differnently. A poll() for POLLOUT will be
> woken by a POLLHUP condition, yet a select() for output will _not_ be
> woken by a POLLHUP condition.

The issue here was a little bit different. On the contrary to poll(2),
with epoll and fd in resident inside the interest set, and epoll allows
you to set the interest event mask to 0. In such condition, epoll does
report POLLHUP and POLLERR events of the 0 masked fd, and this was the
original Ben's argoument. Looking at poll(2) though, it seems that it does
the same thing if you set the event mask to 0. So epoll is coherent with
poll(2) in this. I personally believe that an application should handle
those exceptional events in any case, by simply removing the fd from the
epoll set (and lazily freeing the associated userspace data structures).
So, if no big argouments will come against this, I'd rather prefer to keep
such behaviour. OTOH the patch would be trivial (one or two lines) , so
there will be no design problems in doing this.

- Davide