On Sat, Apr 20, 2019 at 1:11 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, Apr 19, 2019 at 2:20 PM Joel Fernandes joel@joelfernandes.org wrote:
According to Linus, POLLHUP usually indicates that something is readable:
Note that if you use the legacy interfaces (ie "select()"), then even just a plain POLLHUP will always just show as "readable".
So for a lot of applications, it won't even matter. Returning POLLHUP will mean it's readable whether POLLIN is set or not (and EPOLLERR will automatically mean that it's marked both readable and writable).
In fact, I'd argue that not a lot of people care about the more esoteric bits at all. If your poll function does POLLIN and POLLOUT, it's fine. Anything else is specialized enough that most people simply won't care. Don't overdesign things too much. You need to have a major reason to care about the other POLL bits.
It's also worth noting that POLLERR/POLLHUP/POLLNVAL cannot be masked for "poll()". Even if you only ask for POLLIN/POLLOUT, you will always get POLLERR/POLLHUP notification. That is again historical behavior, and it's kind of a "you can't poll a hung up fd". But it once again means that you should consider POLLHUP to be something *exceptional* and final, where no further or other state changes can happen or are relevant.
Which kind of makes sense for process exit. So the historical behavior here is in our favor and having POLLIN | POLLHUP rather fitting. It just seems right that POLLHUP indicates "there can be no more state transitions".
Christian