3 ms·
You know, the more I look at the implementation of exit()/rexit()/wait(), the more I think the PID 1's job of reaping zombies is unnecessary. In exit(), instead
by Joker_vD 2y ago
You know, the more I look at the implementation of exit()/rexit()/wait(), the more I think the PID 1's job of reaping zombies is unnecessary. In exit(), instead of reparenting children to PID 1, the process could reparent them to e.g. PID 0 or PID -1, and then instead of swapping its accounting data to disk unconditionally, it could do it only if its parent's own PID is not 0 (or -1) but when it is, it would intstead do the process entry cleanup part that's in wait() on itself. This, I believe, is all that's needed to make to unparented zombie processes self-reaping.
Edit: no, it's not. During the reparenting step, the process should also clean all its zombie children and that may be a long action that involves swapping from disk; so its instead delegated to PID 1 to do it one process at a time. Well, at least now I have at least some of justification for the original design.
- convolvatron 2y agowhy do we really need zombies? isn't this just a question of making sure that the exit status is available if any one cares? and ultimately thats a separable issue from whether or not the death of a process forces the death of others. imagine instead of wait, processes just went away, and we have..lets say a pipe that contains the single byte exit. have we lost anything important?
- Joker_vD 2y agoCongratulations, you've basically reinvented pidfd. But notice that the Sixth Edition didn't yet have "select", so they had to invent a separate, non-fd kind of entity to track the processes and a separate syscall to both check the process status and to free the tracking entity.