On Sat, Apr 20, 2019 at 1:11 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Apr 19, 2019 at 2:20 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> 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
