[cyphar]

The handle solution is definitely better (which is why I mentioned pidfds -- I actually think it might be possible to do this today with SIG_IGN and PIDFD_GET_INFO but it's a little hacky) but Unix only had pids and most descendants only have pids too. In that paradigm the zombie solution is kind of inevitable (as with most other Unix hacks). My point was that it wasn't as simple as "just doing some more work in exit(2)" -- you would need to redesign the process API.

There are loads of other related issues to this of course -- libraries cannot really spawn subprocesses as part of their implementation because programs using the library could see the SIGCHLD by accident. With the right design, the handle approach is better here.

> Reparenting, of course, is not needed for long-running services/daemons, as demonstrated by daemontools, runit, s6, Upstart, systemd, etc.

Because they are spawned as children of the daemon. Reparenting is needed for standard Unix utilities that want to run in the background (especially in an interactive shell). Of course, you can redesign that too if you have a time machine, but it would require more work than you originally intimated.

[Joker_vD]

> you would need to redesign the process API.

Not really, PIDs are unstable, so only the immediate parent of a child can reasonably do anything with a child's PID anyway, PPID is mostly useless; so when a process exits, set PPIDs of all its non-exitted children to 0 or -1, and reap all of its already dead children, recursively. Done!

> Reparenting is needed for standard Unix utilities that want to run in the background.

Well, okay? You don't need any changes in APIs for that.