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

[Jamie Lokier]

Davide Libenzi wrote:
> 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.

Yes.  SUSv3 says POLLHUP, POLLERR and POLLNVAL are always reported
even if not requested.

> 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).

Take a look at the new subject line :)

Linux select() treats it as an input-only condition, implying that
there might be useful things you can do with output to a file
descriptor that's reporting POLLHUP, including waiting for output.

However, SUSv3 says "This event [POLLHUP]and POLLOUT are mutually
exclusive; a stream can never be writable if a hangup has occurred",
implying that Linux select() is the oddity.

> 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.

I agree, in fact I'd argue specifically against changing it.

Programmers familiar with poll() know that you don't have to set
POLLHUP in the input mask -- because SUSv3 says so ("This flag
[POLLHUP] is only valid in the revents bitmask; it is ignored in the
events member").  They'd not be likely to notice a difference that
subtle for epoll, when they convert application code, so it's good
that there isn't a difference.

Btw, I notice epoll never reports POLLNVAL.  Is that correct?

-- 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/