List of Figures

Chapter 1. Introduction

Figure 1.1. Interactive Elixir has documentation built in.

Figure 1.2. ExUnit comes with excellent error messages.

Chapter 2. A whirlwind tour

Figure 2.1. Documentation for the Dict module displayed in iex

Figure 2.2. A list of functions available in the Dict module

Figure 2.3. Documentation for Dict.put/3

Figure 2.4. Documentation for File.read/1

Figure 2.5. The ID3 tag is located in the last 128 bytes of the MP3.

Figure 2.6. The layout of the ID3 tag

Figure 2.7. How the MP3 is destructured

Figure 2.8. Destructuring the ID3 binary

Figure 2.9. [1,2,3] represented as a picture

Figure 2.10. The httpc:request/1 Erlang documentation

Figure 2.11. Screenshots from Observer

Chapter 3. Processes 101

Figure 3.1. Weather actor handling a single request

Figure 3.2. It’s always helpful to look at the README for third-party libraries to check for important installation instructions.

Figure 3.3. Creating an account and getting an API key from OpenWeatherMap

Figure 3.4. Without concurrency, the next request has to wait for the previous one to complete. This is inefficient.

Figure 3.5. The order of sent messages isn’t guaranteed when processes don’t have to wait for each other.

Figure 3.6. When the first result comes in, the actor saves the result in a list.

Figure 3.7. When the coordinator receives the next message, it stores it in the results list again. (continued on next page)

Figure 3.8. When the coordinator receives the next message, it stores it in the results list again. (continued from previous page)

Figure 3.9. When the coordinator receives the :exit message, it returns the results in alphabetical order and then exits.

Chapter 4. Writing server applications with GenServer

Figure 4.1. The Observer tool displaying the supervisor tree of the kernel application

Chapter 5. Concurrent error-handling and fault tolerance with links, monitors, and processes

Figure 5.1. When a process dies, all other processes linked to it will die, too (assuming they aren’t trapping exits).

Figure 5.2. A ring of linked processes. Notice that each process has two other processes in its link set.

Figure 5.3. What happens when process 2 is killed?

Figure 5.4. A supervision tree can be layered with other supervision trees. Both supervisors and workers can be supervised.

Chapter 6. Fault tolerance with Supervisors

Figure 6.1. The completed worker-pool application

Figure 6.2. Versions 1 and 2 of Pooly

Figure 6.3. Versions 3 and 4 of Pooly

Figure 6.4. Pooly version 1

Figure 6.5. How Pooly’s various components are initialized

Figure 6.6. Named processes allow other processes to reference them by name.

Figure 6.7. A reference to the supervisor is stored in the state of the Pooly server.

Figure 6.8. Version 1 of Pooly as seen in Observer

Figure 6.9. Killing a worker in Observer

Figure 6.10. The Supervisor replaced a killed worker with a newly spawned worker.

Figure 6.11. Killing the server process in Observer

Figure 6.12. Killing the server restarted all the processes under the top-level Supervisor.

Chapter 7. Completing the worker-pool application

Figure 7.1. A possible design to handle multiple pools

Figure 7.2. Another possible design. Can you identify the bottleneck?

Figure 7.3. The final design of Pooly

Figure 7.4. Starting from the top-level Supervisor

Figure 7.5. Logic from the top-level pool server from the previous version will be moved into individual pool servers.

Figure 7.6. Implementing the individual pool Supervisors

Figure 7.7. Implementing the individual pool’s worker Supervisor

Figure 7.8. The Pooly supervision tree as seen in Observer

Chapter 8. Distribution and load balancing

Figure 8.1. The number of requests is split across the available nodes in the cluster. Once a node has received results from all of its workers, the respective node reports back to the worker.

Figure 8.2. Location transparency means essentially no difference between sending a message to a process on the same node and to a process on a remote server.

Figure 8.3. Connecting a node to another node automatically links the new node to all the other nodes in the cluster.

Figure 8.4. The Blitzy supervision tree

Figure 8.5. Using flat_map to flatten the list of Task structs, and then mapping each Task struct to the Blitzy task Supervisor

Figure 8.6. Running Blitzy on my machine

Chapter 9. Distribution and fault tolerance

Figure 9.1. The different options type can take. Note the takeover and failover options.

Figure 9.2. All requests are handled by a@host, no matter which node receives the request.

Figure 9.3. If a@host fails, within five seconds a failover node takes over. b@host takes over automatically once it has detected that a@host has failed

Figure 9.4. Once a@host is back, it initiates a takeover.

Chapter 11. Property-based and concurrency testing

Figure 11.1. An inverse function

Figure 11.2. Using a simpler implementation to test against a tested implementation

Figure 11.3. Concuerror showing a blocked process

Figure 11.4. Concuerror showing a race condition