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 -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
