[Erlang Study Notes] Erlang behaviour Summary of gen_server

First, it is clear that gen_server provides server implementation in the C/S architecture, that is, it defines its own set of standardized server frameworks.

Based on the above, we will learn how to implement gen_server.

First, define the module's behavior pattern as gen_server

-module(lqg).-behaviour(gen_server).  .

Now that the gen_server framework is used, you must implement the gen_server method: gen_server callbacks.

-export([init/1, handle_call/3, handle_cast/2, handle_info/2,  terminate/2, code_change/3]).

External call function of the add-on module: API

-export([start_link/0]).

-export([alloc/0,free/1]).

The following describes how to implement the functions defined above:

start_link() ->      gen_server:start_link({local, lqg}, lqg, [], []).

For start_link,
The first parameter is to create a server named name. Now, in gen_srever, the server will be registered locally as LQG.
The second parameter LQG is the name of the callback module, that is, the module where the callback function is placed. Here, the interface functions (start_link) and callback functions (init, handle_call and handle_cast ). In general, this is a good programming practice. It indicates that the code of the same process is included in the same module.
The third parameter [] will be passed to the callback function init. Here, init will ignore this parameter without any input data.
The fourth parameter [] is the list of parameters.
Note the following:
1. gen_server: start_link is synchronized. It will be returned only when gen_server is fully initialized and ready to accept the request.
2. If gen_server is part of a supervision tree, that is, gen_server is initiated by a supervision tree, you must use
Gen_server: start_link. Another function gen_server: Start is used to start an independent gen_server, which is not a gen_server part of a supervision tree.

init(_Args) ->      {ok, channels()}.

After the name is successfully registered, the new gen_server process will call the callback function LQG: Init ([]).
Init returns {OK, State}, where state is the internal state of gen_server. Here, the status is available channel channels.

alloc() ->     gen_server:call(lqg,alloc).

Synchronous request alloc () is implemented using gen_server: Call/2. LQG is the name of gen_server and must be the same as the name at startup. Alloc is the actual request
In this case, the request is sent to the gen_server as a message. After receiving the request, gen_server calls handle_call (request, from, state) and returns a tuple {reply, reply, state1 }. Reply is the response to be returned to the client, and state1 is the new value of gen_server status.

handle_call(_Request, _From, State) ->      {Ch, State2} = alloc(State),     {reply, Ch, State2}。

Here, the response is the allocated channel CH, and gen_server will wait for the new request, and now a list of available channels is kept up to date.

handle_cast({free,Ch},Chs) ->     Chs2 = free(Ch,Chs),    {noreply, Chs2}.

Here, the new status is the updated list of available channels chs2. Gen_server can now accept new requests.

free(Ch) ->     gen_server:cast(lqg,{free,Ch}).

Asynchronous request free (CH) implemented using gen_server: Cast/2
LQG is the name of gen_server. {Free, CH} is the actual request.
The request is loaded in a message and sent to the cast of gen_server. This calls free and returns OK. When gen_server receives the request, it calls handle_cast (request, stats) and returns a tuple {noreply, state1 }. State1 is a new value of gen_server status.

handle_info(_Info, State) ->      {noreply, State}.

Used to process information other than the request.

terminate(_Reason, _State) ->      ok.

Terminate a function to terminate a running process.

If gen_server is part of a supervision tree, you do not need to stop the function. Its supervisor will automatically terminate it;

If gen_server is not part of a supervision tree, you can use a stop function;
If some cleanup is required before termination, the close policy must be a timeout value, and gen_server must be set to capture the exit signal in the init function. When gen_server is required to be disabled, it will call the callback function terminate (shutdown, State ).

code_change(_OldVsn, State, _Extra) ->      {ok, State}.

As its name suggests, this function is used to replace the code version. It is the process status that is changed by calling back during server hot deployment or code upgrade.
_ Oldvsn: the old version state: internal status of gen_server _ extra: The update command passed in intact
If the update is successful, {OK, state2} is returned. If the update fails, {error, reason} is returned and rolled back to the old version.

Detailed Erlang gen_server API (English version) http://www.erlang.org/doc/man/gen_server.html