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 t

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.