News for hackers. Stuff that matters.
Re:Ghosts of Unix past, part 3: Unfixable designs (2010) by jjnoakes on Monday May 17, 2021 @09:00PM (#27190212)
The waitpid() call isn't quite as broken; I think there are only races there if there is any chance other parts of your process call waitpid() on the same pid and it gets reaped twice.

Under normal operation (pid returned from fork, waitpid used in one spot until the child exits, no odd sigchild shenanigans), I don't think waitpid() has any races.

Am I missing anything?

Re:Ghosts of Unix past, part 3: Unfixable designs (2010) by zxzax on Tuesday May 18, 2021 @08:43AM (#27193824)
The issue I know of is, you cannot really use waitpid(-1, ...) in the same process as waitpid(<pid>, ...), as it would create a race condition on which call consumes the pid first. You can mitigate it in some programs by doing a lookup after the waitpid(-1, ...), but still it's not really reliable for libraries to spawn child processes and use that function. See for example the notes here: https://developer.gnome.org/glib/stable/glib-The-Main-Event-...

If you need to multiplex a wait for multiple processes, it's safer to use epoll with several pidfds. But you still eventually may need to call waitid(-1, ...) to reap any forked processes, and there really is no good way around that.