GenServer.handle_call
handle_call
, go back to GenServer module for more information.
Specs
handle_call(request :: term(), from(), state :: term()) :: {:reply, reply, new_state} | {:reply, reply, new_state, timeout() | :hibernate | {:continue, term()}} | {:noreply, new_state} | {:noreply, new_state, timeout() | :hibernate | {:continue, term()}} | {:stop, reason, reply, new_state} | {:stop, reason, new_state} when reply: term(), new_state: term(), reason: term()
Invoked to handle synchronous call/3
messages. call/3
will block until a
reply is received (unless the call times out or nodes are disconnected).
request
is the request message sent by a call/3
, from
is a 2-tuple
containing the caller's PID and a term that uniquely identifies the call, and
state
is the current state of the GenServer
.
Returning {:reply, reply, new_state}
sends the response reply
to the
caller and continues the loop with new state new_state
.
Returning {:reply, reply, new_state, timeout}
is similar to
{:reply, reply, new_state}
except that it also sets a timeout.
See the "Timeouts" section in the module documentation for more information.
Returning {:reply, reply, new_state, :hibernate}
is similar to
{:reply, reply, new_state}
except the process is hibernated and will
continue the loop once a message is in its message queue. However, if a message is
already in the message queue, the process will continue the loop immediately. Hibernating a
GenServer
causes garbage collection and leaves a continuous heap that
minimises the memory used by the process.
Returning {:reply, reply, new_state, {:continue, continue}}
is similar to
{:reply, reply, new_state}
except handle_continue/2
will be invoked
immediately after with the value continue
as first argument.
Hibernating should not be used aggressively as too much time could be spent garbage collecting. Normally it should only be used when a message is not expected soon and minimising the memory of the process is shown to be beneficial.
Returning {:noreply, new_state}
does not send a response to the caller and
continues the loop with new state new_state
. The response must be sent with
reply/2
.
There are three main use cases for not replying using the return value:
- To reply before returning from the callback because the response is known before calling a slow function.
- To reply after returning from the callback because the response is not yet available.
- To reply from another process, such as a task.
When replying from another process the GenServer
should exit if the other
process exits without replying as the caller will be blocking awaiting a
reply.
Returning {:noreply, new_state, timeout | :hibernate | {:continue, continue}}
is similar to {:noreply, new_state}
except a timeout, hibernation or continue
occurs as with a :reply
tuple.
Returning {:stop, reason, reply, new_state}
stops the loop and terminate/2
is called with reason reason
and state new_state
. Then, the reply
is sent
as the response to call and the process exits with reason reason
.
Returning {:stop, reason, new_state}
is similar to
{:stop, reason, reply, new_state}
except a reply is not sent.
This callback is optional. If one is not implemented, the server will fail if a call is performed against it.