Difference between erlang:send_after and timer:send_after?

Fredrik Andersson sedrik@REDACTED
Tue Jun 29 10:17:47 CEST 2010


Hi all

These two functions seems to be doing the exact same thing (sending a
message after a certain amount of time) but I was wondering why they
are both there. Should timer:send_after not be replacing
erlang:send_after or am I missing something here? None of them seems
to be deprecated, which is the preferred one to use?

Sorry for the silly question.


from the documentation concerning timer:

send_after(Time, Pid, Message) -> {ok, TRef} | {error,Reason}
send_after(Time, Message) -> {ok, TRef} | {error,Reason}

    * Time = integer() in Milliseconds
    * Pid = pid() | atom()
    * Message = term()
    * Result = {ok, TRef} | {error, Reason}

send_after/3

    Evaluates Pid ! Message after Time amount of time has elapsed.
(Pid can also be an atom of a registered name.) Returns {ok, TRef}, or
{error, Reason}.
send_after/2

    Same as send_after(Time, self(), Message).

and the module erlang documentation:

erlang:send_after(Time, Dest, Msg) -> TimerRef

    * Time = int()
    *  0 <= Time <= 4294967295
    * Dest = pid() | RegName
    *  LocalPid = pid() (of a process, alive or dead, on the local node)
    * Msg = term()
    * TimerRef = ref()

Starts a timer which will send the message Msg to Dest after Time milliseconds.

If Dest is an atom, it is supposed to be the name of a registered
process. The process referred to by the name is looked up at the time
of delivery. No error is given if the name does not refer to a
process.

If Dest is a pid, the timer will be automatically canceled if the
process referred to by the pid is not alive, or when the process
exits. This feature was introduced in erts version 5.4.11. Note that
timers will not be automatically canceled when Dest is an atom.

See also erlang:start_timer/3, erlang:cancel_timer/1, and erlang:read_timer/1.

Failure: badarg if the arguments does not satisfy the requirements
specified above.


More information about the erlang-questions mailing list