Module:code_change(OldVsn,State,Extra)->{ok,NewState}|{error,Reason}
Types:
OldVsn = Vsn | {down, Vsn}
Vsn = term()
State = NewState = term()
Extra = term()
Reason = term()
Note:
This callback is optional, so callback modules need not export it. If a release upgrade/downgrade
with Change={advanced,Extra} specified in the appup file is made when code_change/3 isn't
implemented the process will crash with an undef exit reason.
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.
Module:format_status(Opt,[PDict,State])->Status
Types:
Opt = normal | terminate
PDict = [{Key, Value}]
State = term()
Status = term()
Note:
This callback is optional, so callback modules need not export it. The gen_server module provides
a default implementation of this function that returns the callback module state.
This function is called by a gen_server process in the following situations:
* One of sys:get_status/1,2 is invoked to get the gen_server status. Opt is set to the atom
normal.
* The gen_server process terminates abnormally and logs an error. Opt is set to the atom
terminate.
This function is useful for changing the form and appearance of the gen_server status for these
cases. A callback module wishing to change the sys:get_status/1,2 return value, as well as how its
status appears in termination error logs, exports an instance of format_status/2 that returns a
term describing the current status of the gen_server process.
PDict is the current value of the process dictionary of the gen_server process..
State is the internal state of the gen_server process.
The function is to return Status, a term that changes the details of the current state and status
of the gen_server process. There are no restrictions on the form Status can take, but for the
sys:get_status/1,2 case (when Opt is normal), the recommended form for the Status value is [{data,[{"State",Term}]}], where Term provides relevant details of the gen_server state. Following this
recommendation is not required, but it makes the callback module status consistent with the rest
of the sys:get_status/1,2 return value.
One use for this function is to return compact alternative state representations to avoid that
large state terms are printed in log files.
Module:handle_call(Request,From,State)->Result
Types:
Request = term()
From = {pid(),Tag}
State = term()
Result = {reply,Reply,NewState} | {reply,Reply,NewState,Timeout}
| {reply,Reply,NewState,hibernate}
| {reply,Reply,NewState,{continue,Continue}}
| {noreply,NewState} | {noreply,NewState,Timeout}
| {noreply,NewState,hibernate}
| {noreply,NewState,{continue,Continue}}
| {stop,Reason,Reply,NewState} | {stop,Reason,NewState}
Reply = term()
NewState = term()
Timeout = int()>=0 | infinity
Continue = term()
Reason = term()
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.
Module:handle_cast(Request,State)->Result
Types:
Request = term()
State = term()
Result = {noreply,NewState} | {noreply,NewState,Timeout}
| {noreply,NewState,hibernate}
| {noreply,NewState,{continue,Continue}}
| {stop,Reason,NewState}
NewState = term()
Timeout = int()>=0 | infinity
Continue = term()
Reason = term()
Whenever a gen_server process receives a request sent using cast/2 or abcast/2,3, this function is
called to handle the request.
For a description of the arguments and possible return values, see Module:handle_call/3.
Module:handle_continue(Continue,State)->Result
Types:
Continue = term()
State = term()
Result = {noreply,NewState} | {noreply,NewState,Timeout}
| {noreply,NewState,hibernate}
| {noreply,NewState,{continue,Continue}}
| {stop,Reason,NewState}
NewState = term()
Timeout = int()>=0 | infinity
Continue = term()
Reason = normal | term()
Note:
This callback is optional, so callback modules need to export it only if they return
{continue,Continue} from another callback. If continue is used and the callback is not
implemented, the process will exit with undef error.
This function is called by a gen_server process whenever a previous callback returns {continue,Continue}. handle_continue/2 is invoked immediately after the previous callback, which makes it
useful for performing work after initialization or for splitting the work in a callback in
multiple steps, updating the process state along the way.
For a description of the other arguments and possible return values, see Module:handle_call/3.
Module:handle_info(Info,State)->Result
Types:
Info = timeout | term()
State = term()
Result = {noreply,NewState} | {noreply,NewState,Timeout}
| {noreply,NewState,hibernate}
| {noreply,NewState,{continue,Continue}}
| {stop,Reason,NewState}
NewState = term()
Timeout = int()>=0 | infinity
Reason = normal | term()
Note:
This callback is optional, so callback modules need not export it. The gen_server module provides
a default implementation of this function that logs about the unexpected Info message, drops it
and returns {noreply,State}.
This function is called by a gen_server process when a time-out occurs or when it receives any
other message than a synchronous or asynchronous request (or a system message).
Info is either the atom timeout, if a time-out has occurred, or the received message.
For a description of the other arguments and possible return values, see Module:handle_call/3.
Module:init(Args)->Result
Types:
Args = term()
Result = {ok,State} | {ok,State,Timeout} | {ok,State,hibernate}
| {ok,State,{continue,Continue}} | {stop,Reason} | ignore
State = term()
Timeout = int()>=0 | infinity
Reason = term()
Whenever a gen_server process is started using start/3,4, start_monitor/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},
{ok,State,hibernate}, or {ok,State,{continue,Continue}} 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 {continue,Continue} is specified, the process will execute the Module:handle_continue/2
callback function, with Continue as the first argument.
If the initialization fails, the function is to return {stop,Reason}, where Reason is any term, or
ignore. An exit signal with this Reason (or with reason normal if ignore is returned) is sent to
linked processes and ports, notably to the process starting the gen_server when start_link/3,4 is
used.
Module:terminate(Reason,State)
Types:
Reason = normal | shutdown | {shutdown,term()} | term()
State = term()
Note:
This callback is optional, so callback modules need not export it. The gen_server module provides
a default implementation without cleanup.
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 logger(3erl).
When the gen_server process exits, an exit signal with the same reason is sent to linked processes
and ports.
Install Now
PNG Icons
