Who needs handles for processes when you can have reusable IDs instead? /s

For a while the limit has been around 4 million or something like that, instead of the traditional 32k. Which of course broke a bunch of stuff that assumed "char pid[5];" is good enough. Fun stuff.

The kernel offers up this (here abbreviated) example which you could use for all accesses to /proc/<pid> when you have an open pidfd to ensure that the two refer to the same process:

    static int pidfd_metadata_fd(pid_t pid, int pidfd) {
            char path[100];
            snprintf(path, sizeof(path), "/proc/%d", pid);
            int procfd = open(path, O_DIRECTORY | O_RDONLY | O_CLOEXEC);
            if (sys_pidfd_send_signal(pidfd, 0, NULL, 0) < 0 && errno != EPERM) {
               close(procfd);
               procfd = -1;
            }
            return procfd;
    }

And these days you even can poll for pidfds (readable = exited) and you can even use P_PIDFD with waitid. So the very basic process management cycle can be done through pidfds nowadays.

> as far as I know you still can't implement something like pstree without just reading files from `/proc` which is shit.

It's also slow! Tools like top/htop/ps -aux etc. use a surprising amount of CPU because they have to do a trillion trips to the kernel and back. Compare this to the win32 equivalent where, iirc, there is just one or two trips to the kernel to acquire a snapshot and you walk that in user-space instead.