1. A server process is a beam process that use recurive call (loop) to handle different messages.
   
   • Instead of directly handle different message in that server process, we provide the server process with a callback module.
     
2. The key to understand ServerProcess and callback module is:
   
   • The state related with our custom module is maintained inside server process, not by callback module(client) itself.
     
   • Therefore, the callback module is a group of pure functions.
     
   • For example in KeyValueStore, the state which is a map of key and value is updated not in the KeyValueStore module but in the ServerProcess module, in its recursive loop.
     
   • callback functions are always invoked in the server process., such as init/0 and handle_call/2.
     
   • interface functions are run in the client processes.
     

1. The generic server process does
   
   1. use endless recursive call to loop
      
   2. in loop, maintain state
      
   3. provide 2 type of interface functions to let callback module handle messages: one for sync, another for async.
      
2. The callback module receive and handle’s the specific message.
   
   1. callback module call ServerProcess.start to register itself
      
   2. callback module handle messages by calling ServerProcess.call or ServerProcess.cast.
      
      • So, those messages are sent into server process in which the state could be updated.
        
      • The ServerProcess.call or ServerProcess.cast will send message to server_pid, so the messages are process in recursive loop.
        
   3. ServerProcess.call/cast goes into server process’s loop.
      In ServerProcess’s recursive loop:
      
      • The message is processed by callback module’s :handle_call or :handle_cast which all need to return a new state.
        
      • For :call, we need to send message back before loop with new state.
        
        • Because the ServerProcess.call is blocking to receive this message.
          
      • After ServerProcess.call or ServerProcess.cast return. This goes back to in callback module 2).
        

1. Define server callback functions:
   
   • init/1
     
   • handle_cast/2
     
   • handle_call/3
     
2. Define client API:
   
   • Use GenServer.start/2 to start the process.
     
   • Use GenServer.cast/2, GenServer.call/2 to issue requests.
     
3. Some notes
   
   • The client is any process that invokes the client/interface functions.
     
   • The server is always the process identify or process name that we explicitly pass as argument to the client API.
     

• During loop in server process, it needs to maintain state. So the state needed to be carried in loop as argument.
  
• This also means, the callback module called inside the loop need to accept that state as argument.
  
• So, in GenServer, the state is carried as
  
  • the last argument for server all callbacks
    
  • the last element in the return tuple
    

• We may need to handle messages that aren’t specific to GenServer.
  
  • For example, periodically send message by :timer.send_interval(5000, :cleanup).
    

• Use GenServer callback handle_info to handle it:
  

  def handle_info(:cleanup, state) do
    IO.puts "performance cleanup"
    {:noreply, state}
  end
  

1. A client process starts the server by calling GenServer.start and providing the callback module. This creates the new server process which is powered by GenServer.
   
2. When a message is received, GenServer invokes callback functions to handle it. Therefore, callback functions are always executed in server process.
   
3. The client process state is maintained in the GenServer loop but it is defined and manipulated by the callback functions:
   
   • It starts with init/1 which defines the initial state that is then passed to subsequent handle_* callbacks.
     
   • Each of those callbacks receive the current state and must return its new version, which is used by the GenServer loop in place of the old one.
     
4. A GenServer cheat sheet
   

• Make server process do things in sequential way.
  
• Spawn multiple server processes to handle concurrency.
  
• In general,
  
  • if we need to do synchronization between multiple processes, we let one dedicate process to handle these.
    
  • make concurrent process run independently.
    

• Goal: a distributed HTTP server than can handle many end users who are simultaneously manipulating many to-do lists.
  
• Component
  
  • A pure functional Todo.List abstraction.
    
  • A to-do server process that can be used to manage one to-do list for a long time.
    

  • A cache for managing a map: we create Todo.Server instances or fetch the existing ones.
    

    • key is the to-do list name
      
    • value is the to-do server pid.
      

    This is how we work with multple to-do lists: run one instance of the existing to-do server for each to-do list.
    

BEAM distinguish 3 types of runtime errors :error, :exit, or :throw.

1. For :error
   
   • For example, invalid arithmetic expression, call a nonexistent function, patter-matching error.
     
   • You can raise your own error by using raise/1 macro. If a function eplicitly raises an error, it should be appended with the ! character to its name, for instance, File.open!.
     
2. For :exit
   
   • Use exit/1 to exit the current process.
     
3. For :throw
   
   • throw(:thrown_value)
     
   • The purpose of throws is allow nonlocal returns.
     

1. If two processes are linked, and one of the terminates, the other process receives a exit signal, a notification that a process has crashed.
   
   • A exit signal contains the pid of the crashed process and the exit reasion.
     
2. When a process terminates abnormally, the linked process is also take down.
   
3. How to create linked process
   
   • If a link is created when you start a process, use spawn_link/1.
     
   • Otherwise, use Process.link/1 which connect the current process with another process.
     

4. Usually we don’t want a linked process to crash. We could detect the process crash using trapping exits.
   

   spawn(fn ->
     Process.flag(:trap_exit, true)
     spawn_link(fn -> raise("something went wrong") end)
   
     Process.sleep(1000)
     receive do
       msg -> IO.inspect(msg)
     end
   end)
   

   • Format of the exit singal message is: {:EXIT, from_pid, exit_reason}.
     
     • If a process is terminated due to a throw or an error, the exit reason is a tuple in the form {reason, where}.
       
     • If a process is terminated due to an exit, the reason is a term provided to exit/1.
       

1. Make the current process monitor the target process.
   

   monitor_ref = Proccess.monitor(target_pid)
   

   • If the monitored process dies, your process receives a message in the format:
     {:DOWN, monitor_ref, :process, from_pid, exit_reasion}.
     

2. Stop the monitor
   

   Process.demonitor(monitor_ref)
   

3. Exits are propagated through GenServer calls.
   When you issue a synchronous request via GenServer.call, if a server process crashes, an exit signal will occur in your client process.
   

• A supervisor is a generic process whose only responsibility is to receive links and monitor notifications, and do something when a process crashes.
  
• Processes that aren’t supervisors are called workers.
  
• When invoke Supervisor.start_link(child_specs, options), the following happens:
  
  1. The new process is started, powered by the Supervisor module.
     
  2. The supervisor process goes through the list of child specifications and starts each child, one by one.
     
  3. Each specification is resolved, if needed, by invoking child_spec/1 from the corresponding module.
     
     • The child_spec/1 function is automatically defined when we use Agent, GenServer and Supervisor, etc.
       
  4. The supervisor starts the child process, according to the :start filed of the child specification.
     

• Start the supervisor as a module
  

  defmodule Todo.System do
    def start_link do
      Supervisor.start_link(
        [Todo.Cache],
        strategy: :one_for_one
      )
    end
  end
  
  # Todo.System.start_link()
  

  Another callback module way to use supervisor
  

  defmodule Todo.System do
    use Supervisor
  
    def start_link do
      Supervisor.start_link(__MODULE__, nil)
    end
  
    @impl true 
    def init(_) do
      Supervisor.init([Todo.Cache], strategy: :one_for_one)
    end
  end
  

  Note: A general guideline is to use the supervisor without a callback module only at the top of your supervision tree, generally in the Application.start/2 callback. We recommend using module-based supervisors for any other supervisor in your application, so they can run as a child of another supervisor in the tree.
  

• Every time you add a new child to a supervisor, it is important to evaluate if the supervisor strategy is correct as well as the order of child processes.
  

• Learned functions
  

  # Get the pid from registered name
  cache_pid = Process.whereis(Todo.Cache)
  
  # Kill the process
  Process.exit(cache_pid, :kill)
  
  # Verify what the injected implementation of child_spec/1 returns:
  Todo.Cache.child_spec(nil)
  
  # check the number of running processes:
  :erlang.system_info(:process_count)
  

• Explain start_link, child_spec,
  
• Why use ETS?
  
  • Notice that before our changes KV.Registry.lookup/2 sent requests to the server, but now it reads directly from the ETS table, which is shared across all processes. That’s also the main idea behind the cache mechanism we are implementing.
    
• Differences between task, agents, generic servers, and supervisors.
  
  • Common
    
  • Different
    
• About task
  
  • Pass a two-element tuple as child specification, which in turn will invoke Task.start_link/1.
    

1. Different ways to execute Tasks
   Given the existing module.
   

   defmodule Fib do
     def of(0), do: 0
     def of(1), do: 1
     def of(n), do: Fib.of(n-1) + Fib.of(n-2)
   end 
   

   1. Execute Tasks from annonymous function
      

      IO.puts "Start the task"
      worker = Task.async(fn -> Fib.of(20) end)
      IO.puts "Do something else"
      result = Task.await(worker)
      

   2. Execute Tasks directly by specify module, function and arguments
      

      worker = Task.async(Fib, :of, [20])
      result = Task.await(worker)
      IO.puts "The result is #{result}"
      

2. How to suppervise Tasks
   Because Tasks are implemented as OTP servers, they can be added to application’s suppervision tree.
   

   1. Use Task.Supervisor
      

      # 1. Add the task supervisor to the supervision tree
      Supervisor.start_link([
        {Task.Supervisor, name: MyApp.TaskSupervisor}
      ], strategy: :one_for_one)
      
      # 2. Use async/await by passing the name of the supervisor
      Task.Supervisor.async(MyApp.TaskSupervisor, fn ->
        # Do something
      end)
      |> Task.await()
      

   2. By calling Task.start_link instead of Task.asyn. (For fire-and-forget tasks).
      

   3. Wrap Task in its own module similar to how we would do with a GenServer. (For fire-and-forget tasks).
      

      defmodule MyTask do
        use Task
      
        def start_link(arg) do
          Task.start_link(__MODULE__, :run, [arg])
        end
      
        def run(arg) do
          # ...
        end
      end
      
      # Then passing it to the supervisor
      Supervisor.start_link([
        {MyTask, arg}
      ], strategy: :one_for_one)
      

• Agents are a simple abstraction around state.
  
• The Agent module provides a basic server implementation that allows state to be retrieved and updated via a simple API.
  

What is the point of task if we could spawn and receive message so easily.

# using spawn 
current = self()
child = spawn(fn -> send(current, {self(), 1 + 2}) end)

receive do
  value -> value 
end

# using task
task = Task.async(fn -> {self(), 1 + 2} end)
Task.await(task)

• There is less in the primary functionality of starting another process, but much more in the surrounding context.
  
• Spawned proccess neither implement common OTP functionality nor are they supervisied.
  

• Use the simplest approach that works.
  
• Wrapping your agents and tasks in modules. Such that, you can always switch from them to the full-blown GenServer without affecting the rest of the code.
  
• Some key points of GenServer.
  
  • A GenServer process is a general purpose server process which maintains some state.
    
  • When we start a GenServer process, we start it on a different process from the current one.
    

1. an atom
   
   • This includes module names.
     
2. a {:global, term} tuple, like {:global, :job_runner}
   
   • This registers the process globally. Useful for distributed applications.
     
3. a {:via, module, term} tuple
   
   • where module is an Elixir module that would take care of the registration process, using the value term.
     

• Atoms are note garbage collected by the Erlang VM, and there are soft limits.
  

• It allows us to use strings, rather than atoms, which don’t have the same limitation.
  
• Each Registry works as a process which we have to include in our application supervision tree.
  
• The usage of Registry (see: Registry – Hex docs)
  
  1. Using in :via, it can be used to register and access named process.
     
     • In this case, we specify the key as “:unique”.
       
  2. Using as a dispatcher and PubSub
     
     • In this case, we specify the keys as “:duplicate”
       
     • Use Registry.dispatch/3 to invoke callbacks
       

• Example01
  

  # First, in application when specify children of supervision tree
  children = [
    {Registry, keys: unique, name: Jobber.JobRegistry}
    ...
  ]
  
  # Then, in GenServer' start_link
  GenServer.start_link(__MODULE__, args, name: {:via, Registry, {Jobber.JobRegistry, key, value}})
  

• You only add stages acoording to the runtime needs, typically when we need to provide back-pressure or leverage concurrency.
  
• Rule of thumb
  
  • Always start with plain functions.
    
  • When you recognize the need for using back-pressure, create a 2-stage data pipeline first.
    
  • Gradually extend pipeline when spot an opportunity for improvement.
    

• What is back-pressure mechanism.
  

1. one-to-one, GenStage.DemandDispatcher
   
2. one-to-many, GenStage.BroadcastDispatcher
   
   • Let each consumer how to do the futher processing.
     
3. one-to-many, GenStage.PartitionDispatcher
   
   • Let producer examines each event, and assigns it to a partition (like bucket).