On Fri, Apr 19, 2019 at 4:33 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, Apr 19, 2019 at 4:20 PM Christian Brauner christian@brauner.io wrote:
On Sat, Apr 20, 2019 at 1:11 AM Linus Torvalds torvalds@linux-foundation.org wrote:
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".
Note that that is *not* true of process exit.
The final state transition isn't "exit", it is actually "process has been reaped". That's the point where data no longer exists.
FWIW, I think the exit status should be available via pidfd even after process reaping. A non-parent holder of a pidfd has no ability to control when the parent reaps the child, or even if reaping is necessary at all --- the parent could make SIGCHLD SIG_IGN. Someone trying to read exit status via a pidfd shouldn't fail to get that exit status just because he lost the race with a concurrent waitpid().