Many of these problems are at least partially solved on other UNIX systems like illumos. To run down the top-level list: 1. It's easy for processes to leak i

Many of these problems are at least partially solved on other UNIX systems like illumos. To run down the top-level list: 1. It's easy for processes to leak illumos has contracts[1][2][3], which were developed as part of the Service Management Facility[4]. They are another process grouping abstraction that allows SMF to track trees of processes, whether they daemonise or not. They allow for tracking or ignoring certain events (e.g., a fatal signal sent from outside the contract, a process within the contract that aborts and dumps core, if a particular process, or all processes, terminate in some way) and for doing certain kinds of automatic cleanup (e.g., terminate all processes in the contract when the process that owns the contract is terminated). These are managed by the kernel, so they are effectively inescapable even when not held correctly by a user process. 2. It's impossible to prevent malicious processes leaks This is not really true for us either. Between contracts, and resource controls[5], and privileges[6], I expect one would be able to limit the malicious or accidental escape of processes from supervision or any run-away resource consumption caused by, say, a fork bomb. 3. Processes have global, reusable IDs This is true on some level, but in practice I think that's just part of UNIX and when you have solved 1-2 and 4 in other ways, it's not actually that bad. If you want to kill everything in a contract you own, even without knowing the full list of pids, you can do that with ct_ctl_abandon(3CONTRACT)[7] which takes a contract file descriptor. The termination action (which could be to tear down all of the processes) will take effect then. 4. Process exit is communicated through signals This is not entirely true, in the sense that they are by default for classic UNIX applications -- but they need not be. We have forkx(2)[8], which has the FORK_NOSIGCHLD and FORK_WAITPID flags. These request that SIGCHLD is not posted for process termination, and that the classic UNIX wait(2) family of calls will not receive notification or reap children. You can use these from a library, and then manage your own waitid(2) or waitpid(3C) calls on the specific process IDs you are responsible for reaping. You can also use contracts to receive notifications of events about processes within the contract coming and going. [1]: https://illumos.org/man/5/contract https://illumos.org/man/5/contract [2]: https://illumos.org/man/3LIB/libcontract https://illumos.org/man/3LIB/libcontract [3]: https://illumos.org/man/3CONTRACT/ https://illumos.org/man/3CONTRACT/ [4]: https://illumos.org/man/7/smf https://illumos.org/man/7/smf [5]: https://illumos.org/man/7/resource_controls https://illumos.org/man/7/resource_controls [6]: https://illumos.org/man/7/privileges https://illumos.org/man/7/privileges [7]: https://illumos.org/man/3CONTRACT/ct_ctl_abandon https://illumos.org/man/3CONTRACT/ct_ctl_abandon [8]: https://illumos.org/man/2/forkx https://illumos.org/man/2/forkx