Messages in this thread | | | From | Daniel Colascione <> | Date | Wed, 31 Oct 2018 12:56:12 +0000 | Subject | Re: [RFC PATCH] Minimal non-child process exit notification support |
| |
On Wed, Oct 31, 2018 at 12:27 PM, David Laight <David.Laight@aculab.com> wrote: > From: Daniel Colascione >> Sent: 29 October 2018 17:53 >> >> This patch adds a new file under /proc/pid, /proc/pid/exithand. >> Attempting to read from an exithand file will block until the >> corresponding process exits, at which point the read will successfully >> complete with EOF. The file descriptor supports both blocking >> operations and poll(2). It's intended to be a minimal interface for >> allowing a program to wait for the exit of a process that is not one >> of its children. > > Why do you need an extra file?
Because no current file suffices.
> It ought to be possible to use poll() to wait for POLLERR having set > 'events' to zero on any of the nodes in /proc/pid - or even on > the directory itself.
That doesn't actually work today. And waiting on a directory with POLLERR would be very weird, since directories in general don't do things like blocking reads or poll support. A separate file with self-contained, well-defined semantics is cleaner.
> Indeed, to avoid killing the wrong process you need to have opened > some node of /proc/pid/* (maybe cmdline) before sending the kill > signal.
The kernel really needs better documentation of the semantics of procfs file descriptors. You're not the only person to think, mistakenly, that keeping a reference to a /proc/$PID/something FD reserves $PID and prevents it being used for another process. Procfs FDs do no such thing. kill(2) is unsafe whether or not /proc/pid/cmdline or any other /proc file is open.
| |