I want to start a gen_server that additionally, will perform one action every minute.
What is the best way to schedule that?
You have two easy alternatives, use timer:send_interval/2
or erlang:send_after/3
. send_interval
is easier to setup, while send_after
(when used in the Erlang module) is more reliable since it is a built-in function, see the Efficiency Guide.
Using send_after
also ensures that the gen_server
process is not overloaded. If you were using the send_interval
function you would get a message regardless if the process can keep up or not. With send_after
being called just before the return in handle_info
you only schedule a new message once you handled the previous one. If you want more accurate time tracking you can still schedule a send_after
with the time set dynamically to something lower than ?INTERVAL
(or even 0) to catch up.
I would recommend something along the following lines in your gen_server
:
-define(INTERVAL, 60000). % One minute
init(Args) ->
... % Start first timer
erlang:send_after(?INTERVAL, self(), trigger),
...
handle_info(trigger, State) ->
... % Do the action
... % Start new timer
erlang:send_after(?INTERVAL, self(), trigger),
...
Instead of trigger
you could send something with a state if it is needed, like {trigger, Count}
or something.
To precisely control the timer, you may want to use erlang:start_timer
, and save each timer reference you have created.
erlang:start_timer
has a tiny difference with erlang:send_after
, see http://www.erlang.org/doc/man/erlang.html#start_timer-3 and http://www.erlang.org/doc/man/erlang.html#send_after-3
Example use case:
init(Args) ->
...
TRef = erlang:start_timer(?INTERVAL, self(), trigger),
State = #state{tref = TRef},
...
handle_info({timeout, _Ref, trigger}, State) ->
%% With this cancel call we are able to manually send the 'trigger' message
%% to re-align the timer, and prevent accidentally setting duplicate timers
erlang:cancel(State#state.tref),
...
TRef = erlang:start_timer(?INTERVAL, self(), trigger),
NewState = State#state{tref = TRef},
...
handle_cast(stop_timer, State) ->
TRef = State#state.tref,
erlang:cancel(TRef),
%% Remove the timeout message that may have been put in our queue just before
%% the call to erlang:cancel, so that no timeout message would ever get
%% handled after the 'stop_timer' message
receive
{timeout, TRef, _} -> void
after 0 -> void
end,
...
There is actually a built-in mechanism within gen_server to accomplish the same thing.
If the third element of response tuple of the init, handle_call, handle_cast or handle_info methods in the gen_server
is an integer, a timeout
message wil be sent to the process after that period of time in millisecs... which should be handled using handle_info. For eg :
init(Args) -> ... % Start first timer {ok, SomeState, 20000}. %% 20000 is the timeout interval handle_call(Input, From, State) -> ... % Do something ... % Do something else {reply, SomeState, 20000}. %% 20000 is the timeout interval handle_cast(Input, State) -> ... % Do something ... % Do something else {noreply, SomeState, 20000}. %% 20000 is the timeout interval %% A timeout message is sent to the gen_server to be handled in handle_info %% handle_info(timeout, State) -> ... % Do the action ... % Start new timer {noreply, SomeState, 20000}. %% "timeout" can be sent again after 20000 ms
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With