OSDev.org

What exactly is the purpose of a process hierarchy where processes own each other? Is there any benefits of this which can't be realized with only a flat model where no process owns no other process?

If you have more then one process dependent on each other, then the parent child relation if beneficial. If the parent dies all the children can also be released thus returning resources to the system. Also lookups within processes are faster because you do not have to traverse the whole list of all processes. Arguably there might be only one process and a lot of child threads but that is dependent of your design.

If you think you do not need the parent child relationship then you don not need it.

Typically if a parent dies, nothing interesting happens to the children, other than they become independent (or children of some generic process, in unix this would be init).

Rather, it's the other case that is more interesting: having child-parent relationships makes it easy to notify the parents when their children die. Say, a command line shell would want to wait until the process you started is finished, before the shell prompts you for another command. Or when you run a program from a .ZIP archive, your archive program will temporarily unpack the archive, and then wants to know when the process is finished, so it can clean up the temporary files..

Ofcourse having such a hierarchy also makes it easy to kill process trees, say, a given login shell and everything under it.. but then again usually it's easy to escape the parent-relationship if you really want to (in Unix you'd just fork() the process, let the parent exit, and do your work in the child, though typically you do this twice for reasons of getting rid of terminal and login session and whatever.. can't be bother to remember the details now).

But I don't see why it's necessary to restrict this to child processes. Why not a wait call that takes a process id and waits until it ends?

Two reasons:

1) Without a parent making a seperate list of all children it has fork()ed, there is no way for it to wait until ALL it's children have exited (c.f. wait() - doesn't take a parameter, will wait for ANY child to exit).

2) When a process has exited and been waited on, we say it has been 'harvested'. If two processes (possibly one malicious) try to harvest another process, it is arbitrary which one will harvest successfully. If the parent didn't manage it, it may return with an error code or worse, sit in an infinite loop. Keeping a child the parent's responsibility solves this problem.

(please note that under *nix systems another process can wait for an arbitrary process to exit (note perl code not C):

The important point is a non-parent process cannot harvest another.)

Well, actually there is a way -- even in a generic *nix. The job table that PS accesses and displays shows the parent PID of all running threads. The task can wait until its own PID does not show up as the parent of anything.

But that assumes there is a process heirarchy, which the OP is questioning.

I just killed a runaway script that had spawned several hundreds of sub-processes, seriously clogging up the system.

Finding all spawns of that runaway script would have been a real pain if there hadn't been a parent-child connection between the processes, allowing me to "kill this process and all its childs".

Well, it assumes that your OS keeps some kind of informal record of which threads spawned which other threads. You can do that without creating a full formal process heiracrchy, but your point is taken.

well, imho, you can keep track of who-spawned-who in whatever way you want, that still remains encoding of a graph where some process/thread/whatever have arcs towards others p/t/w and that graph is inevitably a tree (you can't have been spawn by your brother nor can you point towards your grandfather).

i don't know what you mean with "full formal process hierarchy" ... keeping the list of threads you've spawn or a pointer to your parent thread is typically just an optimization for common operations to avoid walking the process table again and again.