On 19.04.19 23:21, Daniel Colascione wrote:
EPOLLIN on a pidfd could very well mean that data can be read via a read() on the pidfd *other* than the exit status. The read could e.g. give you a lean struct that indicates the type of state transition: NOTIFY_EXIT, NOTIFY_EXEC, etc.. This way we are not bound to a specific poll event indicating a specific state. Though there's a case to be made that EPOLLHUP could indicate process exit and EPOLLIN a state change + read().
And do you imagine making read() destructive? Does that read() then reset the POLLIN state? You're essentially proposing that a pidfd provide an "event stream" interface, delivering notifications packets that indicate state changes like "process exited" or "process stopped" or "process execed". While this sort of interface is powerful and has some nice properties that tools like debuggers and daemon monitors might want to use, I think it's too complicated and error prone for the overwhelmingly common case of wanting to monitor process lifetime.
I don't think it's so complicated. read() + comparing a few bits (eg. strncmp(), if the packets are strings) really isn't a big deal.
Actually, I proposed quite the same (before I read this mail).
I like Linus' idea of just making waitid(2) (not waitpid(2), as I mistakenly mentioned earlier) on a pidfd act *exactly* like a waitid(2) on the corresponding process and making POLLIN just mean "waitid will succeed". It's a nice simple model that's easy to reason about and that makes it easy to port existing code to pidfds.
Okay, that's probably a good starting point. We could add more sophisticated monitoring later.
--mtx