Erlang---Gen_server

Behavioral patterns

Gen_server represents one of the "behavioral patterns", the purpose of which is to provide a set of templates for a particular type of process.

Start the server

Used to start the server there are,, start/3 start/4 start_link/3 , start_link/4 these four functions. With these start functions, a new process is generated, that is, a gen_server server. The normal return value of these start functions is the {ok,Pid} Pid process number of the new process. The difference between a link and a non-band is whether it is linked to the parent process, in other words, if the newly started process dies, it will not notify the initiating process (parent process).

The start function can be of four parameters (ServerName, Module, Args, Options) :

• ServerName is a service name that can be omitted. A module with the same service name can only be started once in a node, and repeated boot will be error-  {error, {already_started, Pid}} . A service process with a service name can be called with a service name, and no service name can be invoked only through the process number PID. A service process with a name usually uses the module name as the service name, which is the macro -define (SERVER) defined in the above template. MODULE) , and then fill in where you want to use the service name? SERVER .

• The second parameter module is the module name, and the API and callback functions are generally written in the same file, so use   ? Module , which represents the modules name of this module.

• The third parameter Args is the parameter of the callback function INIT/1 . is passed to init/1 intact.

• fourth parameter options is an option to set debug, timeout, and so on.

The callback function for Start is init/1 , in general, some initialization work after the server starts, and generates the initial state, and the normal return is {OK, status}. This state is the link that runs through the server and connects all six callback functions. Its value is initially init/1 generated and can then be modified by three handle functions, which are then put back into the return value for use by the next called handle function after each modification. If init/1 returned ignore or {stop, Reason} , the start of the server is aborted. One thing to note is that API functions and callback functions are traditionally written in the same file, but the process of executing the function is usually different. In the above template, start_link/0 if used, the self() caller's process number is displayed, and the init/1 self() server's process number is displayed when used in. using the server

The callback function at the beginning of the three handle corresponds to three different ways of using the server. As follows:

Gen_server:call     -------------   handle_call/3gen_server:cast     -------------   HANDLE_CAST/2! Send a message to the service process   -------------   HANDLE_INFO/2

call is called with a return value, cast is a call without a return value, which is notification, and a message sent directly to the server process is handled by Handle_info. call is called with a return value, and is also called a synchronous call, and the process waits until the callback function returns after the call. It's in the form of a function gen_server:call(ServerRef, Request, Timeout) -> Reply ,

• The first parameter ServerRef is the server that is called, either the server name or the server's PID.
• The second parameter Request is passed directly to the callback functionhandle_call。
• The last parameter Timeout is a timeout, which can be omitted, and the default value is 5 seconds.

Call is used to direct the callback function to handle_call/3 work. The specific form is handle_call(Request, From, State) .

• The first parameter Request is sent in by call and is the focus of attention and processing when writing the program.
• The second parameter From is Gen_server, which is the source of the call, that is, which process has called. Fromthe form is {Pid, Ref} the Pid source process number, and the Ref identity of the call, each call is different, to distinguish. With PID, you can use it when you need to send a message to the source process, but because call has a return value, it is generally good to use the return value to pass the data.
• The third parameter State is the state of the server, which is generated by init or other handle functions that can be modified as needed before being put back in the return value.

PagerThe callback function for call is normally returned as the return value of call, which is handle_call/3 {reply, Reply, NewState} used as the state of the Reply NewState server. You can also use the {stop, Reason, State} abort server to run, which is less used.

Use call to be careful, the two server processes cannot be on each other, or they will deadlock.

cast

Cast is a call with no return value, which is generally called notification. It is an "asynchronous" call that is received directly after the call ok , without waiting for the callback function to complete.

It's in the form of gen_server:cast(ServerRef, Request) . The parameter means the same as call. Since there is no need to wait for a return, there is no need to set the timeout, without a third parameter.

In the case of multiple nodes, it can be used to abcast send a notification to a service process with the specified name on each node. (Strange is why do not bark multi_cast , obviously looks multi_call like)

The cast's corresponding callback function is handle_cast/2 , specifically: handle_cast(Msg, State) . The first parameter is cast in, and the second is the server state, similar to call, not much.

handel_cast/2The return value is usually {noreply, NewState} , this can be used to change the server state, or {stop, Reason, NewState} , this will stop the server. In general, the command to stop a server is implemented with cast for more.

Native Message

Native messages are messages that are sent directly to the server process without call or cast, and some books are translated as "out-of-band" messages. Let's say the network socket socket sends the message, the other process uses! The message sent, the process of establishing a link to the server died, and {‘EXIT‘, Pid, Why} so on. Generally write programs to use the API, do not use directly! Send a message to the server process, but for a message-dependent application such as a socket, you have to process the native message.

The native message handle_info/2 is used for processing, specifically handle_info(Info, State) . where info is the content of the message that is sent over. The reply handle_cast is the same.  stopping the server

The handle function described above returns {stop,...} and uses a callback function terminate/2 to mop up the work. Typically close open resources, files, network Connections, log records, notify other processes "I'm going to die", or "letter Chun brother, Full blood Resurrection": Use the incoming state to restart the server.

The simplest is to do nothing, return to OK is good.

Erlang---Gen_server