One of the interesting things about processes in Unix is that they are tree structured. This is easily seen with the pstree command; init is the root of all processes. Several things, can, however go wrong with this tree. Defunct or zombie processes show up when a child process dies and the parent is unaware. Likewise, orphan processes occur when the parent dies and the child is still running. Despite the names, neither is a tragedy. Zombie processes are removed from the process table when the parent dies, and orphans become the children of init. Thus, the strict tree structure is maintained.
Compare this to a multithreaded system. Threads are not forked from other threads. They have no explicit parent other than the enclosing process or address space. If we treat threads like objects in a garbage collected OO environment (i.e. we need to have a reference to a thread in order for it to survive), we quickly see they are not tree structured like Unix processes. One thread can create five new threads, pass the references to other threads, and disappear. There is no parent/child relationship, and the newly created threads needn’t care about the status of the thread in which they were originally created. The representation of these relationships is not a tree, but rather a graph that evolves over time.
What does this have to do with erlang-in-lisp? The light-weight processes in Erlang are much closer to the graph-nature of multithreaded systems, and with our current approach, we will have to map this graph onto a the Unix process tree.
The simplest approach is to have each process wait for its children to complete before exiting or returning. This should probably be our first approach. However, in larger or long running systems, this could become a burden, with many short-lived processes hanging around and taking up memory (though not cycles) while their longer-lived children run to completion.