* Christian Brauner: > Ok, I finally have access to source code again. Scratch what I said above! > I looked at the code and tested it. If the process has exited but not > yet waited upon aka is a zombie procfd_send_signal() will return 0. This > is identical to kill(2) behavior. It should've been sort-of obvious > since when a process is in zombie state /proc/<pid> will still be around > which means that struct pid must still be around. Should we make this state more accessible, by providing a different error code? Will the system call ever return ESRCH, given that you have a handle for the process? >> >Looking at the rt_tgsigqueueinfo interface, is there a way to implement >> >the “tg” part with the current procfd_signal interface? Would you use >> >openat to retrieve the Tgid: line from "status"? > > Yes, the tg part can be implemented. I meant on top of the existing interface. > As I pointed out in another mail my I is to make this work by using > file descriptors for /proc/<pid>/task/<tid>. I don't want this in the > initial patchset though. I prefer to slowly add those features once > we have gotten the basic functionality in. Do you want to land all this in one kernel release? I wonder how applications are supposed to discover kernel support if functionality is split across several kernel releases. If you get EINVAL or EBADF, it may not be obvious what is going on. What happens if you use the new interface with an O_PATH descriptor? Thanks, Florian
