Messages in this thread | | | Date | Sat, 3 Apr 2004 23:35:41 +0100 | From | Jamie Lokier <> | Subject | Re: Is POLLHUP an input-only or bidirectional condition? (was: epoll reporting events when it hasn't been asked to) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |