spawn(fn ->\r\n IO.puts \"In #{inspect self()} process\"\r\nend)<\/pre>\nBut if this process happens to fail for whatever reason, we\u2019ll never know about it. It is completely isolated and won\u2019t affect our current process at all.<\/p>\n
spawn(fn ->\r\n IO.puts \"Uh oh...\"\r\n raise(\"I have failed you.\")\r\nend)\r\n\r\n:timer.sleep(500)\r\nIO.puts \"I'm done.\"<\/pre>\nThe reason our process that spawned this code wasn\u2019t affected at all is because they aren\u2019t linked. You\u2019ll notice that it still printed the \"I'm done.\"<\/code> message. Linking ties two or more processes together\u2026if one process fails, so does the process that is linked to it. To begin a new linked process, you change the above code only slightly to call the spawn_link<\/code> function instead.<\/p>\nspawn_link(fn ->\r\n IO.puts \"Uh oh...\"\r\n raise(\"I have failed you.\")\r\nend)\r\n\r\n:timer.sleep(500)\r\nIO.puts \"I'm done.\"<\/pre>\nNow that we have linked the process to our current (self()<\/code>) process, it won\u2019t print the \"I'm done.\"<\/code> message. When the linked process went down, so did our current one. Links are bidirectional. It doesn\u2019t matter which process fails; by linking them, they are both effected.<\/p>\nSo what if we actually did want to recover from a failure in a linked process? To do this, we will have to do something called trapping exits<\/em>. When a linked process fails, we are given an opportunity to recover from it. We can listen for exits using a receive<\/code> block, the typical way that messages are passed from one process to another.<\/p>\nTell our current process that we want to trap exits\r\nProcess.flag(:trap_exit, true)\r\n\r\n# Spawn a linked process which will fail\r\nspawn_link(fn ->\r\n IO.puts \"Uh oh...\"\r\n raise(\"I have failed you.\")\r\nend)\r\n\r\n# Receive the trapped exit message\r\nreceive do\r\n {:EXIT, pid, :normal} ->\r\n IO.inspect \"Normal exit from #{inspect pid}\"\r\n {:EXIT, pid, msg} ->\r\n IO.inspect \":EXIT received from #{inspect pid}\"\r\n IO.inspect msg\r\nend\r\n\r\n:timer.sleep(500)\r\nIO.puts \"I'm done.\"<\/pre>\nYou\u2019ll notice that in the receive<\/code> block above, I am actually pattern matching for two different :EXIT<\/code> messages. The first one is what happens when a process exits normally upon finishing its task. The second one will catch errors and in our case will output:<\/p>\n:EXIT received from #PID<0.73.0>\r\n{%RuntimeError{message: \"I have failed you.\"},\r\n [{:elixir_compiler_0, :\"-__FILE__\/1-fun-0-\", 0,\r\n [file: 'error_linking_traps.exs', line: 5]}]}<\/pre>\nMonitoring Processes<\/h2>\n
Links are bidirectional, but monitoring on the other hand is unidirectional. It allows you to monitor (hence the name) the status of another process without linking yourself to it. You\u2019re observing it at a safe distance. Unlike linking, an error in a monitored process won\u2019t bring down your current one; you\u2019ll just be notified of it.<\/p>\n
# Spawn a new process and grab its pid\r\npid = spawn(fn ->\r\n :timer.sleep 500\r\n raise(\"Sorry, my friend.\")\r\nend)\r\n\r\n# Set up a monitor for this pid\r\nref = Process.monitor(pid)\r\n\r\n# Wait for a down message for given ref\/pid\r\nreceive do\r\n {:DOWN, ^ref, :process, ^pid, :normal} ->\r\n IO.puts \"Normal exit from #{inspect pid}\"\r\n {:DOWN, ^ref, :process, ^pid, msg} ->\r\n IO.puts \"Received :DOWN from #{inspect pid}\"\r\n IO.inspect msg\r\nend<\/pre>\nWe\u2019ll see the following:<\/p>\n
Received :DOWN from #PID<0.73.0>\r\n{%RuntimeError{message: \"Sorry, my friend.\"},\r\n [{:elixir_compiler_0, :\"-__FILE__\/1-fun-0-\", 0,\r\n [file: 'error_monitoring.exs', line: 3]}]}<\/pre>\nSupervising<\/h2>\n
Linking and monitoring are available when you need them, but Elixir comes with Supervisor functionality. This allows us to easily define what behavior should occur when the code that is being supervised fails. We\u2019ll use an example of a cache store, which fetches the cached value as long as it hasn\u2019t expired.<\/p>\n
In the code below, we first fetch the total<\/code> value, providing a function to call if it doesn\u2019t exist or if it has already expired. We then identify the pid of this named process, which is 0.109.0<\/code>. After sending a :kill<\/code> message to the process, we then identify the pid again and can see that it is now 0.115.0<\/code>. It has automatically been restarted by its supervisor and is now able to fetch the total<\/code> value again (which would need to be recalculated because all state was lost when the process was killed).<\/p>\niex(1)> CashMan.Cache.fetch('total', fn -> 20 end)\r\n20\r\niex(2)> pid = Process.whereis(CashMan.Cache)\r\n#PID<0.109.0>\r\niex(3)> Process.exit(pid, :kill)\r\ntrue\r\niex(4)> Process.whereis(CashMan.Cache)\r\n#PID<0.115.0>\r\niex(5)> CashMan.Cache.fetch('total', fn -> 20 end)\r\n20<\/pre>\nBecause this example runs as an application, we\u2019ll implement the start<\/code> function which is called automatically. Its job in this case is to start the Supervisor<\/code> module for this application by calling the start_link<\/code> function. Supervisors, like any other concurrent code in Elixir, are simply a specialized process.<\/p>\ndefmodule CashMan do\r\n use Application\r\n\r\n def start(_type, _args) do\r\n CashMan.Supervisor.start_link\r\n end\r\nend<\/pre>\nThe implementation for the Supervisor<\/code> module includes the use Supervisor<\/code> statement. This gives us all of the functionality which comes built in to Elixir for this behavior<\/a>.<\/p>\nWe\u2019ll call the start_link<\/code> function that comes with Supervisor, passing it the __MODULE__<\/code> (our current module, to use as the supervising module), an initial value, which in our case is simply :ok<\/code>, and the name of this process.<\/p>\nThe init<\/code> function is then called automatically, which is where we can define the exact behavior for this specific supervisor: which children will it supervise, and which strategies should be used in case they fail.<\/p>\nSupervisors can supervise children (GenServers), but they can also supervise other supervisors, creating a supervision hierarchy or tree. Benjamin Tan Wei Hao<\/a> produced an excellent cheatsheet<\/a> detailing all of the different functions and options for supervisors.<\/p>\ndefmodule CashMan.Supervisor do\r\n use Supervisor\r\n\r\n def start_link do\r\n Supervisor.start_link(__MODULE__, :ok, name: CashMan.Supervisor)\r\n end\r\n\r\n def init(:ok) do\r\n children = [\r\n worker(CashMan.Cache, [CashMan.Cache])\r\n ]\r\n\r\n supervise(children, [strategy: :one_for_one])\r\n end\r\nend<\/pre>\nA good overview of the different strategies<\/a> can be found in this article, and although it is speaking about Erlang, the restart strategies are identical in Elixir.<\/p>\nI chose to use :one_for_one<\/code> in the example above because the supervisor is only supervising one child. You would also use this strategy when it is an isolated process that shouldn\u2019t effect any other children that the supervisor is supervising.<\/p>\nBelow we have the child, which implements the GenServer<\/a> behavior. If you are looking for more details on how a GenServer works, please refer to my previous article on Concurrency Abstractions in Elixir<\/a>.<\/p>\ndefmodule CashMan.Cache do\r\n use GenServer\r\n\r\n @default_expiry 60\r\n\r\n def start_link(name) do\r\n GenServer.start_link(__MODULE__, %{}, name: name)\r\n end\r\n\r\n # Allow async fetching, which returns a `Task`,\r\n # allowing you to call `Task.await()` at a later date.\r\n def async_fetch(key, func, expiry \\\\ @default_expiry) do\r\n Task.async(fn ->\r\n fetch(key, func, expiry)\r\n end)\r\n end\r\n\r\n # Fetch the fresh value for a given key\r\n # If missing or expired, re-generate a new value and store it in the cache.\r\n def fetch(key, func, expiry \\\\ @default_expiry) do\r\n case GenServer.call(__MODULE__, {:fetch, key, expiry}) do\r\n :missing ->\r\n value = Task.async(fn -> func.() end) |> Task.await()\r\n store(key, value, expiry)\r\n value\r\n value -> value\r\n end\r\n end\r\n\r\n # Store a given value in the cache, providing its expiry time in seconds\r\n def store(key, value, expiry) do\r\n GenServer.cast(__MODULE__, {:store, key, value, expiry})\r\n end\r\n\r\n # Remove all expired entries from the cached\r\n def prune do\r\n GenServer.cast(__MODULE__, :prune)\r\n end\r\n\r\n # Return the current state of the cache\r\n def current do\r\n GenServer.call(__MODULE__, :current)\r\n end\r\n\r\n # Server\r\n\r\n def handle_call({:fetch, key, _expiry}, _from, state) do\r\n {answer, new_state} = case Map.fetch(state, key) do\r\n {:ok, {expired_at, value}} ->\r\n case expired?(expired_at) do\r\n true -> {:missing, Map.delete(state, key)}\r\n false -> {value, state}\r\n end\r\n :error ->\r\n {:missing, state}\r\n end\r\n {:reply, answer, new_state}\r\n end\r\n\r\n def handle_call(:current, _from, state) do\r\n {:reply, state, state}\r\n end\r\n\r\n def handle_cast({:store, key, value, expiry}, state) do\r\n new_state = Map.put(state, key, {calc_expired_at(expiry), value})\r\n {:noreply, new_state}\r\n end\r\n\r\n def handle_cast(:prune, state) do\r\n new_state = Enum.reduce(state, %{}, fn ({key, {expired_at, value}}, new_state) ->\r\n if (expired?(expired_at)) do\r\n new_state\r\n else\r\n Map.put(new_state, key, {expired_at, value})\r\n end\r\n end)\r\n {:noreply, new_state}\r\n end\r\n\r\n def calc_expired_at(expiry) do\r\n (DateTime.utc_now() |> DateTime.to_unix()) + expiry\r\n end\r\n\r\n def expired?(expired_at) do\r\n DateTime.to_unix(DateTime.utc_now()) > expired_at\r\n end\r\nend<\/pre>\nBy calling :observer.start<\/code> in any iex console, you will be able to see examples of supervisors. Logging<\/code> contains one which you can explore! Ours from the example above looks like the following:<\/p>\n![\"\"](\"http:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2017\/04\/cash-man.png\")
<\/a><\/p>\nConclusion<\/h2>\n
For a deeper dive into the world of Elixir and OTP, I recommend The Little Elixir and OTP Guidebook<\/em><\/a>. It does a great job diving much deeper into each of the subjects we touched on above. The topic of supervisors in Elixir is much deeper and more nuanced than I could have hoped to cover in a single article. As usual, the Elixir website has an excellent guide on supervisors<\/a> also.<\/p>\nThe cool thing about Elixir is that all of the more advanced\/abstracted functionality is built on top of the building blocks of processes<\/em>, which can link<\/em> themselves to other processes and send<\/em> and receive<\/em> messages from one process to another. Everything else is an abstraction, including a supervisor which is just a specialized GenServer that comes with the language.<\/p>\n\n