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

[Jamie Lokier]

[New thread because I want people who understand POLLHUP to clarify.
 The parent thread's question was: why does epoll always report POLLHUP
 and POLLERR conditions even when the program didn't ask for those.
 The trivial answer is because that's what poll() does.]

Davide Libenzi wrote:
> Handling by, for example, removing the fd from the epoll set and 
> unregistering/freeing the associated data structures. IMO we can leave the 
> current behaviour, but if someone sees huge problems with this, the fix is 
> a one-liner.

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.

Perhaps that indicates some confusion over what POLLHUP is supposed to
mean, and when it should be set by devices and/or sockets: is it for
input hangup conditions that allow further output, or for total hangup
conditions where input and output are both guaranteed to fail?

If it's the latter, as it seems to be for sockets, then the poll() and
epoll behaviour makes sense, but select() doesn't.  If it's the
former, then the select() behaviour is the only one that makes sense.

Hence my question: does anyone know for sure which POLLHUP behaviour
is correct and sensible?

-- Jamie


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