今天benjamin同學在網上問了以下問題：

我在看mochiweb和misultin的程式碼時有一些不理解的地方，以下是程式碼：

init({MainSupRef, Port, OptionsTcp, AcceptorsPoolsize, RecvTimeout, SocketMode, CustomOpts}) ->
?LOG_DEBUG(“starting listening ~p socket with options ~p on port ~p”, [SocketMode, OptionsTcp, Port]),
case misultin_socket:listen(Port, OptionsTcp, SocketMode) of
{ok, ListenSocket} ->
Acceptors = [
{{acceptor, N}, {misultin_acceptor, start_link, [MainSupRef, ListenSocket, Port, RecvTimeout, SocketMode, CustomOpts]},
permanent, brutal_kill, worker, dynamic}
|| N ],
{ok, {{one_for_one, 5, 10}, Acceptors}};

我不明白的就是為什麼是dynamic，我檢視supervisor文件，文件上寫只有gen_event才應該是dynamic，而這裡misultin_acceptor這個程序是使用proc_lib:spawn_link產生的。我在proc_lib的文件中也沒有發現這裡為什麼應該使用dynamic。請您指教。

考慮到這種應用很多，而且基本上supervisor文件上講的不是很清楚，所以我花時間調查了下，以下是我調查的過程和結果：

我們從 supervisor的 文件開始，可以看到supervisor規格書的定義：

This is the type definition of a child specification:
child_spec() = {Id,StartFunc,Restart,Shutdown,Type,Modules}
Id = term()
StartFunc = {M,F,A}
M = F = atom()
A = [term()]
Restart = permanent | transient | temporary
Shutdown = brutal_kill | int()>=0 | infinity
Type = worker | supervisor
Modules = [Module] | dynamic
Module = atom()

其中規格里面module部分可以定義為dynamic的只有gen_event，看文件：

Modules is used by the release handler during code replacement to determine which processes are using a certain module. As a rule of thumb Modules should be a list with one element [Module], where Module is the callback module, if the child process is a supervisor, gen_server or gen_fsm. If the child process is an event manager (gen_event) with a dynamic set of callback modules, Modules should be dynamic. See OTP Design Principles for more information about release handling.

Modules should be a list with one element [Module], where Module is the name of the callback module, if the child process is a supervisor, gen_server or gen_fsm. If the child process is a gen_event, Modules should be dynamic.

那麼為什麼mochiweb和misultin要定義成dynamic呢？

在正常情況下，被監督的程序如果死掉了，supervisor會根據規格重新啟動程序或者做出相應的行動。 但是翻看了supervisor.erl所有的程式碼也沒發現dynamic有什麼特殊作用： one_for_one模式下permanent型別的程序出錯，supervisor只是負責重新啟動，其他的也沒做啥。

起先我想不通，但是後來我想到了這個資訊可能和release handler的程式碼熱升級有關係。 在熱升級的時候，針對supervisor管理的程序，需要知道它是由那個模組apply執行的。 這樣才能在模組程式碼發生變更的時候，好判斷出該程序是否要做點升級的準備。 所以規格書不僅僅是給supervisor模組用的，也給release handler模組用。其中的modules部分就是描述那些模組和這個程序有關係。 對於gen_server, gen_fsm behaviour的模組來講， 它的程序由只有它自己spawn_link來的，所以很好理解填規格的時候，模組部分填他自己就好。 但是gen_event這樣的模組，由於一個事件通常會註冊好幾個模組，而且是動態的，所以規格書就不知道填什麼，只好填dynamic. 在熱升級需要知道模組的時候，即刻發訊息現查詢那些模組和這個程序相關。

有了這個理論基礎後，我們來看下release_handler_1.erl:510

%%-----------------------------------------------------------------
%% Func: get_supervised_procs/0
%% Purpose: This is the magic function.  It finds all process in
%%          the system and which modules they execute as a call_back or
%%          process module.
%%          This is achieved by asking the main supervisor for the
%%          applications for all children and their modules
%%          (recursively).
%% NOTE: If a supervisor is suspended, it isn't possible to call
%%       which_children.  Code change on a supervisor should be
%%       done in another way; the only code in a supervisor is
%%       code for starting children.  Therefore, to change a
%%       supervisor module, we should load the new version, and then
%%       delete the old.  Then we should perform the start changes
%%       manually, by adding/deleting children.
%% Returns: [{SuperPid, ChildName, ChildPid, Mods}]
%%-----------------------------------------------------------------
%% OTP-3452. For each application the first item contains the pid
%% of the top supervisor, and the name of the supervisor call-back module.  
%%-----------------------------------------------------------------
...
get_supervised_procs() ->
...
get_procs(_, _Sup) ->
    [].

get_dynamic_mods(Pid) ->
    {ok,Res} = gen:call(Pid, self(), get_modules),
    Res.

我們可以看到 release_handler會給透過gen模組給程序傳送get_modules訊息來獲取相應的模組資訊的, 這個訊息就是 {From, Tag, get_modules} 。

我們來看下gen_event.erl:277是如何處理這個訊息的：

...
  {From, Tag, get_modules} ->
            ?reply(get_modules(MSL)),
            loop(Parent, ServerName, MSL, Debug, false);
...

%% Message from the release_handler.
%% The list of modules got to be a set !
get_modules(MSL) ->
    Mods = [Handler#handler.module || Handler <- MSL],
    ordsets:to_list(ordsets:from_list(Mods)).

到這裡為止，我想大家應該明白了，整個處理流程是如何的，訊息是如何流動的。

那我們再回到mochiweb，結合我們的問題來驗證下。 先看下 mochiweb_socket_server.erl:294:

% this is what release_handler needs to get a list of modules,
% since our supervisor modules list is set to 'dynamic'
% see sasl-2.1.9.2/src/release_handler_1.erl get_dynamic_mods
handle_info({From, Tag, get_modules}, State = #mochiweb_socket_server{name={local,Mod}}) ->
    From ! {element(2,Tag), [Mod]},
    {noreply, State};

% If fo-module(mochiweb_socket_server).
r some reason we can't get the module name, send empty list to avoid release_handler timeout:
handle_info({From, Tag, get_modules}, State) ->
    error_logger:info_msg("mochiweb_socket_server replying to dynamic modules request as '[]'~n",[]),
    From ! {element(2,Tag), []},
    {noreply, State};
    Mods = [Handler#handler.module || Handler <- MSL],
    ordsets:to_list(ordsets:from_list(Mods)).
	    ?reply(get_modules(MSL)),
	    loop(Parent, ServerName, MSL, Debug, false);

他確實處理了get_modules訊息，而且把模組的資訊返回去了。
但是諸位會想，為什麼要返回這個模組呢？ 我們來看下如何使用mochiweb就明白了：
我們看下mochiweb/examples/keepalive/keepalive.erl

-module(keepalive).
-export([ start/1, loop/1
        ]).
%% internal export (so hibernate can reach it)
-export([ resume/3
        ]).

-define(LOOP, {?MODULE, loop}).

start(Options = [{port, _Port}]) ->
    mochiweb_http:start([{name, ?MODULE}, {loop, ?LOOP} | Options]).
...

他傳了{name, ?MODULE}進去，那麼最終這個模組keepalive會被 mochiweb_socket_server.erl的get_modules獲取的到。 也就是說升級的時候，升級模組要檢查keepalive模組是否被變更了。 這就是整個dynamic設計的目的。

流程比較繞，做好一個好的框架確實不容易，要考慮的東西太多。

這裡要注意的是misultin就沒有處理get_modules訊息，所以就會在升級的時候碰到麻煩，不成熟呀！

祝大家玩得開心！

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