2016-07-19 40 views

回答

2

你可以採取爲例在Erlang的外殼會發生什麼,比如考慮序列:

1> self(). 
<0.32.0> 
2> A = 1. 
1 
3> self(). 
<0.32.0> 
4> A = 2. 
** exception error: no match of right hand side value 2 
5> self(). 
<0.37.0> 

1>第一條命令要求給shell提示自己的PID:<0.32.0>

2>接下來一個新的命令將變量A設置爲1,它起作用,因爲A是未綁定的。

3>對shell的新請求顯示其Pid沒有更改。

4>試圖匹配A與整數2失敗,它引發一個異常。事實上,在後臺,shell進程死亡,並且一個主管立即重啓它。

5>可以通過一個新的請求來驗證shell Pid,現在它是<0.37.0>

6>當shell死亡時,它已經丟失了所有信息,並且從頭開始重新啓動。但在初始化期間,它可以連接到負責保存會話歷史的所有其他進程以及所有綁定變量。它可以通過詢問的值進行驗證:

6> A. 
1 

7>或通過詢問病史

7> h(). 
1: self() 
-> <0.32.0> 
2: A = 1 
-> 1 
3: self() 
-> <0.32.0> 
4: A = 2 
-> {'EXIT',{{badmatch,2},[{erl_eval,expr,3,[]}]}} 
5: self() 
-> <0.37.0> 
6: A 

根據不同的環境(硬件故障,通信中斷,壞的參數,錯誤.. )erlang進程可能會因爲錯誤原因而死亡。如果它是在監督樹(或您自己的監控)中進行管理的,則可以從頭開始重新啓動。爲所有流程提供恢復適當狀態的手段是應用責任。

erlang進程也可能因爲「正常」而死亡,例如,當用戶關閉會話時(在shell中鍵入q()。),在這種情況下,超級用戶將不會重新啓動它。

你會發現在網絡上許多有價值的信息:

design principle

erlang.org supervisor

learn you some erlang : run time errors

learn you some erlang : errors and processes

learn you some erlang : supervisors