Serialization handles competing operations one at a time in a defined sequence. A single server process naturally serializes requests, but can become a scalability bottleneck when many client processes depend on it. section 10.3
A server loop serializes access to mutable state by receiving messages, applying each request, and continuing with the resulting state. Extracting state manipulation into a separate module keeps the loop focused on message handling and state progression. section 5.3.4
Use serialization deliberately:
- Keep independent tasks concurrent; avoid concentrating unrelated operations behind one process. section 10.3
- Use a private loop to protect changing state and dispatch each request to a dedicated handler. section 5.3.4
TodoServer
TodoServer serializes add-entry and entries requests around a TodoList. Each message produces a new TodoList value, and the loop continues with that value while callers use a stable server process. section 5.3.4
Listing 5.10 TodoServer basic structure (todo_server.ex)
defmodule TodoServer do
def start do
spawn(fn -> loop(TodoList.new()) end) #1
end
defp loop(todo_list) do
new_todo_list =
receive do
message -> process_message(todo_list, message)
end
loop(new_todo_list)
end
...
end
Inspect the minimal receive-and-loop structure that serializes access to TodoList state. section 5.3.4
