View Source t__srv (t__ v0.1.0)
Link to this section Summary
Functions
Handle gen_server code change This function is called by a gen_server process when it is to update its internal state during a release upgrade/downgrade, that is, when the instruction {update,Module,Change,...}, where Change={advanced,Extra}, is specifed in the appup file. For more information, see section Release Handling Instructions in OTP Design Principles.
Handle gen_server calls Whenever a gen_server process receives a request sent using call/2,3 or multi_call/2,3,4, this function is called to handle the request.
Init gen_server Whenever a gen_server process is started using start/3,4 or start_link/3,4, this function is called by the new process to initialize.
Handle gen_server terminate
Link to this section Functions
Handle gen_server code change This function is called by a gen_server process when it is to update its internal state during a release upgrade/downgrade, that is, when the instruction {update,Module,Change,...}, where Change={advanced,Extra}, is specifed in the appup file. For more information, see section Release Handling Instructions in OTP Design Principles.
For an upgrade, OldVsn is Vsn, and for a downgrade, OldVsn is {down,Vsn}. Vsn is defined by the vsn attribute(s) of the old version of the callback module Module. If no such attribute is defined, the version is the checksum of the Beam file.
State is the internal state of the gen_server process. Extra is passed "as is" from the {advanced,Extra} part of the update instruction.
If successful, the function must return the updated internal state. If the function returns {error,Reason}, the ongoing upgrade fails and rolls back to the old release.Handle gen_server calls Whenever a gen_server process receives a request sent using call/2,3 or multi_call/2,3,4, this function is called to handle the request.
Request is the Request argument provided to call or multi_call. From is a tuple {Pid,Tag}, where Pid is the pid of the client and Tag is a unique tag. State is the internal state of the gen_server process.
If {reply,Reply,NewState} is returned, {reply,Reply,NewState,Timeout} or {reply,Reply,NewState,hibernate}, Reply is given back to From as the return value of call/2,3 or included in the return value of multi_call/2,3,4. The gen_server process then continues executing with the possibly updated internal state NewState.
For a description of Timeout and hibernate, see Module:init/1.
If {noreply,NewState} is returned, {noreply,NewState,Timeout}, or {noreply,NewState,hibernate}, the gen_server process continues executing with NewState. Any reply to From must be specified explicitly using reply/2.
If {stop,Reason,Reply,NewState} is returned, Reply is given back to From.
If {stop,Reason,NewState} is returned, any reply to From must be specified explicitly using reply/2. The gen_server process then calls Module:terminate(Reason,NewState) and terminates.Init gen_server Whenever a gen_server process is started using start/3,4 or start_link/3,4, this function is called by the new process to initialize.
Args is the Args argument provided to the start function. If the initialization is successful, the function is to return {ok,State}, {ok,State,Timeout}, or {ok,State,hibernate}, where State is the internal state of the gen_server process.
If an integer time-out value is provided, a time-out occurs unless a request or a message is received within Timeout milliseconds. A time-out is represented by the atom timeout, which is to be handled by the Module:handle_info/2 callback function. The atom infinity can be used to wait indefinitely, this is the default value.
If hibernate is specified instead of a time-out value, the process goes into hibernation when waiting for the next message to arrive (by calling proc_lib:hibernate/3).
If the initialization fails, the function is to return {stop, Reason}, where Reason is any term, or ignore.-spec start_link(Args :: proplists:proplist()) -> {ok, pid()} | ignore | {error, term()}.
Handle gen_server terminate
This function is called by a gen_server process when it is about to terminate. It is to be the opposite of Module:init/1 and do any necessary cleaning up. When it returns, the gen_server process terminates with Reason. The return value is ignored.
Reason is a term denoting the stop reason and State is the internal state of the gen_server process.
Reason depends on why the gen_server process is terminating. If it is because another callback function has returned a stop tuple {stop,..}, Reason has the value specified in that tuple. If it is because of a failure, Reason is the error reason.
If the gen_server process is part of a supervision tree and is ordered by its supervisor to terminate, this function is called with Reason=shutdown if the following conditions apply: - The gen_server process has been set to trap exit signals. - The shutdown strategy as defined in the child specification of the supervisor is an integer time-out value, not brutal_kill.
Even if the gen_server process is not part of a supervision tree, this function is called if it receives an 'EXIT' message from its parent. Reason is the same as in the 'EXIT' message. Otherwise, the gen_server process terminates immediately.
Notice that for any other reason than normal, shutdown, or {shutdown,Term}, the gen_server process is assumed to terminate because of an error and an error report is issued using error_logger:format/2.