On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: > [..] > > > why do we want to add a new syscall (pidfd_wait) though? Why not just use > > > standard poll/epoll interface on the proc fd like Daniel was suggesting. > > > AFAIK, once the proc file is opened, the struct pid is essentially pinned > > > even though the proc number may be reused. Then the caller can just poll. > > > We can add a waitqueue to struct pid, and wake up any waiters on process > > > death (A quick look shows task_struct can be mapped to its struct pid) and > > > also possibly optimize it using Steve's TIF flag idea. No new syscall is > > > needed then, let me know if I missed something? > > > > Huh, I thought that Daniel was against the poll/epoll solution? > > Hmm, going through earlier threads, I believe so now. Here was Daniel's > reasoning about avoiding a notification about process death through proc > directory fd: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html > > May be a dedicated syscall for this would be cleaner after all. Ah, I wish I've seen that discussion before... syscall makes sense and it can be non-blocking and we can use select/poll/epoll if we use eventfd. I would strongly advocate for non-blocking version or at least to have a non-blocking option. Something like this: evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); // register eventfd to receive death notification pidfd_wait(pid_to_kill, evfd); // kill the process pidfd_send_signal(pid_to_kill, ...) // tend to other things ... // wait for the process to die poll_wait(evfd, ...); This simplifies userspace, allows it to wait for multiple events using epoll and I think kernel implementation will be also quite simple because it already implements eventfd_signal() that takes care of waitqueue handling. If pidfd_send_signal could be extended to have an optional eventfd parameter then we would not even have to add a new syscall. > > I have no clear opinion on what is better at the moment since I have > > been mostly concerned with getting pidfd_send_signal() into shape and > > was reluctant to put more ideas/work into this if it gets shutdown. > > Once we have pidfd_send_signal() the wait discussion makes sense. > > Ok. It looks like that is almost in though (fingers crossed :)). > > thanks, > > - Joel >
