On Mon, Apr 15, 2019 at 10:15 AM Jonathan Kowalski <bl0pbl33p@xxxxxxxxx> wrote: > > Why else do we want pidfd? > > Apart from what others have already pointed out, there are two other > things I am looking forward to: Everything that Christian, Joel, and Jonathan have said is right. If I can wax philosophical for a bit (as I've been accused to doing :-)), there's a lot of value in consistency itself, a "more than the sum of its parts" effect that arises from modeling all kernel-resource handles as file descriptors. You get lifecycle consistency, API consistency (e.g., dup, close), introspection consistency (via /proc/pid/fd and friends), wait consistency, IPC consistency, and tons of other benefits from using a file descriptor. The alternatives tend to be very ugly: one of SysV IPC's* biggest mistakes, for example, was having users manage its resources via non-file-descriptor kernel handles. The process is, I think, the last major class of kernel resource that users can't manipulate via file descriptor. Even if using pidfds didn't provide strong immediate and direct benefits, it'd *still* be worth moving to a file descriptor resource handle model for the sake of making the system interface regular and uniform. * Does anyone know *why* the SysV people didn't use FDs? The consistency argument I'm making was just as relevant then as it is now.
