前段時間arksea同學提出這個問題, 因為文件裡面寫的很不明白.

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.

erlang:start_timer(Time, Dest, Msg) -> TimerRef
Time = int()
0 <= Time <= 4294967295
Dest = LocalPid | RegName
LocalPid = pid() (of a process, alive or dead, on the local node)
RegName = atom()
Msg = term()
TimerRef = ref()
Starts a timer which will send the message {timeout, TimerRef, 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:send_after/3, erlang:cancel_timer/1, and erlang:read_timer/1.

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

表面上看這2個API沒有什麼大的差別,使用上也一樣, 那為什麼要搞二個呢? 好奇怪!

好, 讓我們來好好研究下典型應用.

這2個API都返回 TimerRef. 使用者可以用這個TimerRef來取消定時器. 唯一的差別是在超時的時候傳送的訊息不同: send_after是Msg, start_timer是{timeout, TimerRef, Msg}.
問題就出在取消timer的時候. 如果這個timer還沒有超時的時候, 那麼取消就沒問題. 如果超時了麻煩就來了, 這個訊息已經有可能已經被放到目標程序的訊息佇列裡,等待派遣處理了.

這時候send_after裡面存放的是Msg, 那使用者如何知道Msg是對於那個TimerRef的呢? 讀者可能說, 那我可以在訊息裡面加入TimerRef. 這個主意不錯, 但是問題是在send_after呼叫返回之前, 你是無法得到TimerRef, 當然也就無從構造這個訊息, 那就無法處理這個可能的超時資訊, 就會破壞邏輯.
所以erts version 5.4.11 引入了, start_timer來解決這個問題. 它是自動的在超時後, 要傳送訊息前, 在訊息裡面添加了{timeout, TimerRef, Msg}, 達到識別的目的.

結論: 文件裡面一眼帶過的東西, 其實是有很多設計方面的考慮, 要認真考慮它的存在的意義.

Post Footer automatically generated by wp-posturl plugin for wordpress.