4.7. Process Skeletons

There is a common pattern to the behavior of processes, regardless of their particular purpose. Processes have to be spawned and their aliases registered. The first action of newly spawned processes is to initialize the process loop data. The loop data is often the result of arguments passed to the spawn BIF and the initialization of the process. It is stored in a variable we refer to as the process state. The state is passed to a receive-evaluate function, which receives a message, handles it, updates the state, and passes it back as an argument to a tail-recursive call. If one of the messages it handles is a stop message, the receiving process will clean up after itself and terminate. This is a recurring theme among processes that we usually refer to as a design pattern, and it will occur regardless of the task the process has been assigned to perform. Figure 4-12 shows an example skeleton.

Figure 4-12. A process skeleton

From reoccurring patterns, let’s now look at differences among processes:

• The arguments passed to the spawn BIF calls will differ from one process to another.

• You have to decide whether you should register a process, and, if you do register it, what alias should be used.

• In the function that initializes the process state, the actions taken will differ based on the tasks the process will perform.

• The storing of the process state might be generic, but its contents will vary among processes.

• When in the receive-evaluate loop, processes will receive different messages and handle them in different ways.

• And finally, on termination, the cleanup will vary from process to process.

So, even if a skeleton of generic actions exists, these actions are complemented by specific ones that are directly related to the specific tasks assigned to the process.