On Fri, Apr 19, 2019 at 4:33 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Apr 19, 2019 at 4:20 PM Christian Brauner <christian@xxxxxxxxxx> wrote: > > > > On Sat, Apr 20, 2019 at 1:11 AM Linus Torvalds > > <torvalds@xxxxxxxxxxxxxxxxxxxx> 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().
