การใช้งานพฤติกรรม GenServer

Welcome back! In the previous lesson, we learned about Erlang's OTP behaviors. One of the most important is the GenServer.

• A GenServer is a generic server that handles requests.
• It manages internal state and processes messages in a sequential manner.
• Think of it as a standardized way to build reliable, fault-tolerant server processes in Erlang.

It's the foundation for many Erlang applications.

To implement a GenServer, you define a module that exports specific callback functions. These functions are called by the gen_server behavior at different stages.

• init/1: Initializes the server's state.
• handle_call/3: Handles synchronous client requests (expects a reply).
• handle_cast/2: Handles asynchronous client requests (fire-and-forget).
• terminate/2: Cleans up when the server stops.
• code_change/3: Handles hot code upgrades.

We'll focus on init, handle_call, and handle_cast in this lesson.

Every GenServer starts by initializing its state. This is done in the init/1 callback function.

It takes one argument (typically a list of arguments passed during startup) and should return {ok, State}, where State is the initial data your GenServer will manage.

Here's a basic init function:

To get our GenServer running, we need to start it. The common way is using gen_server:start_link/3 or gen_server:start_link/4. We'll add a start_link/0 function to our module.

The start_link function creates a new Erlang process and links it to the calling process, making it part of a supervision tree (more on this later!).

When a client needs a reply from the server, it makes a synchronous call using gen_server:call/2 or gen_server:call/3.

The GenServer handles these requests in its handle_call/3 callback. This function takes three arguments:

• Request: The message from the client.
• From: The sender's process ID (Pid) and a tag.
• State: The current internal state of the GenServer.

It typically returns {reply, Reply, NewState}.

Let's add an increment function to our counter. This will be a synchronous call, meaning the client waits for the new count.

Try running this code. First, compile it (`c(my_counter).`), then start it (`my_counter:start_link().`). You can then call `my_counter:increment().` to see the counter increase.

Sometimes, a client doesn't need a reply and just wants to send a message without waiting. This is an asynchronous call using gen_server:cast/2.

The GenServer handles these messages in its handle_cast/2 callback. It takes two arguments:

• Message: The message from the client.
• State: The current internal state of the GenServer.

It always returns {noreply, NewState} because no reply is sent back to the client.

Let's add a reset function to our counter. This will be an asynchronous call, as the client doesn't need to know the new count immediately.

Compile and start the module as before. Call `my_counter:increment().` a few times, then `my_counter:reset().`. You'll notice `reset` returns immediately without a value.

The power of GenServers lies in how they manage state. The State argument is passed into each callback, and the callback returns a NewState.

• This ensures that only one process (the GenServer itself) ever modifies its state, preventing race conditions.
• It makes the server's internal logic easier to reason about.
• The state can be any Erlang term: an integer, a list, a map, a record, or a complex data structure.

This sequential processing of messages and explicit state passing is key to Erlang's concurrency model.

You've successfully built your first GenServer! Here's what we covered:

• GenServers are standard OTP behaviors for building stateful servers.
• The init/1 callback initializes the server's state.
• gen_server:start_link creates the GenServer process.
• handle_call/3 handles synchronous requests (client waits for reply).
• handle_cast/2 handles asynchronous messages (client doesn't wait).
• GenServers manage their state by passing it between callbacks, ensuring sequential updates.

Next, we'll see how supervisors can automatically restart failed GenServers!