date: 2010-07-12

之前同事遇到一个问题，系统运行一段时间后有大量的port没有正常关闭而导致beam崩溃，经过定位发现是由于zlib引起的。过程很简单，没什么技术含量，记录一下。

错误信息大致是这样的（原因是传入的数据不是zlib压缩格式）：

** exception error: data_error

     in function  zlib:call/3

     in call from zlib:inflate/2

     in call from zlib:uncompress/1

看call的实现，应该是这里，erlang:error(list_to_atom(Res))，

看了下zlib的解压源码：

-spec uncompress(binary()) -> binary().
uncompress(Binary) when byte_size(Binary) >= 8 ->
    Z = open(),
    inflateInit(Z),
    Bs = inflate(Z, Binary),
    inflateEnd(Z),
    close(Z),
    list_to_binary(Bs);
uncompress(Binary) when is_binary(Binary) -> erlang:error(data_error);
uncompress(_) -> erlang:error(badarg).

open是返回一个port

open() ->
    open_port({spawn, "zlib_drv"}, [binary]).      

close则关闭一个port

close(Z) ->
    try
    true = port_close(Z),
        receive       %In case the caller is the owner and traps exits
            {'EXIT',Z,_} -> ok
        after 0 -> ok
        end
    catch _:_ -> erlang:error(badarg)
    end.

inflate(Z, Data) ->
    try port_command(Z, Data) of
        true ->
            call(Z, ?INFLATE, <<?Z_NO_FLUSH:32>>),
            collect(Z)
    catch
        error:_Err ->
            flush(Z),
            erlang:error(badarg)
    end.
   

   
call(Z, Cmd, Arg) ->
    try port_control(Z, Cmd, Arg) of
        [0|Res] -> list_to_atom(Res);
        [1|Res] ->
            flush(Z),
            erlang:error(list_to_atom(Res));
        [2,A,B,C,D] ->
            (A bsl 24)+(B bsl 16)+(C bsl 8)+D;
        [3,A,B,C,D] ->
            erlang:error({need_dictionary,(A bsl 24)+(B bsl 16)+(C bsl 8)+D})
    catch
        error:badarg -> %% Rethrow loses port_control from stacktrace.
            erlang:error(badarg)
    end.         

erlang在遇到port返回错误时直接error了，典型的非防御性编程。 但是个人认为这个接口应该在抛出错误之前关闭掉打开的port。

日期：2010-08-03

环境：centos  5.5  64     erlang 14A

一、terminate简述及问题产生

terminate是gen_server的一个回调函数，如果一个gen_server进程设置了trap_exit为true（process_flag(trap_exit, true)），则在该进程结束时会自动调用terminate。利用这个功能，我们可以在进程退出时进行一些善后工作，例如持久化数据、清理等等。但实际上terminate不一定有时间完成所有的任务，在此之前可能已经被系统强制结束了(如果使用init:stop形式结束beam)。

二、测试terminate

一个erlang 内部 process结束有两种形式：主动结束（如玩家下线后，玩家进程会自动结束）和被动结束(init:stop)。

系统停止时（init:stop/c:q/erlang:halt），会依次停止所有的进程，如果一个进程是监控树，则该监控树会先依次停止所有的子进程，然后结束自己。对于子进程也是同样的处理方法。

先做测试，后分析源码。测试分为四种情况：

进程主动退出 + simple_one_for_one

init:stop + simple_one_for_one

进程主动退出 + one_for_one

init:stop + one_for_one

源码文件：

test.erl (application)

test_sup.erl (supervisor)

test_server.erl (gen_server)

test.erl源码：

-module(test).

-behaviour(application).

-export([start/0, start/2, stop/1]).

start() ->
    application:start(test).

start(_StartType, _StartArgs) ->
    case test_sup:start_link() of
        {ok, Pid} ->
            {ok, Pid};
        Error ->
            Error
    end.

stop(_State) ->
    ok.

 

非常简单，直接通过 erl -name test@192.168.1.83 -setcookie 123456 -boot start_sasl -s test start 即可启动该app。

test_sup.erl源码：

-module(test_sup).

-behaviour(supervisor).

%% API
-export([start_link/0]).

%% Supervisor callbacks
-export([init/1]).

-define(SERVER, ?MODULE).

start_link() ->
    supervisor:start_link({local, ?SERVER}, ?MODULE, []).

init([]) ->
    RestartStrategy = simple_one_for_one,
    MaxRestarts = 1000,
    MaxSecondsBetweenRestarts = 3600,

    SupFlags = {RestartStrategy, MaxRestarts, MaxSecondsBetweenRestarts},

    Restart = transient,
    Shutdown = 200000,
    Type = worker,

    AChild = {test_server, {test_server, start_link, []},
              Restart, Shutdown, Type, [test_server]},

    {ok, {SupFlags, [AChild]}}.

源码骨架都是emacs生成的，我们只关注RestartStrategy = simple_one_for_one,这里，等会需要改成one_for_one以便测试对比。

test_server.erl

-module(test_server).

-behaviour(gen_server).

-export([
         start/0,
         start_link/0
        ]).

-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).

-define(SERVER, ?MODULE).

-record(state, {}).

start() ->
    {ok, _} = supervisor:start_child(test_sup, []).

start_link() ->
    gen_server:start_link(?MODULE, [], []).

init([]) ->
    erlang:process_flag(trap_exit, true),
    {ok, #state{}}.

handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.

handle_cast(_Msg, State) ->
    {noreply, State}.

handle_info({'EXIT', _, Reason}, State) ->
    io:format("exit:~p~n", [Reason]),
    {stop, normal, State};

handle_info(_Info, State) ->
    {noreply, State}.

terminate(Reason, _State) ->
    io:format("i'm terminate:~p~n", [Reason]),
    timer:sleep(10000),
    io:format("~s", ["end"]),
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

简单说明下test_server：

2． handle_info({'EXIT', _, Reason}, State) -> 方便simple_one_for_one下进程进程退出操作

3． terminate中的清理工作：io → timer:sleep → io

启动命令行：erl -name test@192.168.1.83 -setcookie 123456 -boot start_sasl -s test start

1． 进程主动退出 + simple_one_for_one

(test@192.168.1.83)1> erlang:exit(list_to_pid("<0.51.0>"), test).

exit:test

true

i'm terminate:normal

(test@192.168.1.83)2> end

正常完成了terminate

2． init:stop + simple_one_for_one

 (test@192.168.1.83)1> test_server:start().

{ok,<0.53.0>}

(test@192.168.1.83)2> init:stop().

ok

(test@192.168.1.83)3> i'm terminate:shutdown

[root@ming2_local_dev test]#

可以看到似乎没能正常的处理完terminate

3. 进程主动退出 + one_for_one

(test@192.168.1.83)1> erlang:exit(list_to_pid("<0.51.0>"), test).

exit:test

true

i'm terminate:normal

(test@192.168.1.83)2> end

正常完成了terminate

4． init:stop + one_for_one

(test@192.168.1.83)2> init:stop().

ok

(test@192.168.1.83)3> i'm terminate:shutdown

end[root@ming2_local_dev test]#

ok，很完整的执行了我们的terminate。

terminate执行测试结果

三、底层分析

看起来很奇怪的结果，还是从源码来分析问题。从supervisor开始：

 

terminate(_Reason, State) ->
    terminate_children(State#state.children, State#state.name),
    ok.

 

terminate_children/2 是一个尾递归函数，依次结束每个子进程:

terminate_children(Children, SupName) ->
    terminate_children(Children, SupName, []).

terminate_children([Child | Children], SupName, Res) ->
    NChild = do_terminate(Child, SupName),
    terminate_children(Children, SupName, [NChild | Res]);
terminate_children([], _SupName, Res) ->
    Res.

  

在看do_terminate/2

do_terminate(Child, SupName) when Child#child.pid =/= undefined ->
    case shutdown(Child#child.pid,
          Child#child.shutdown) of
    ok ->
        Child#child{pid = undefined};
    {error, OtherReason} ->
        report_error(shutdown_error, OtherReason, Child, SupName),
        Child#child{pid = undefined}
    end;
do_terminate(Child, _SupName) ->
    Child.

继续：

shutdown(Pid, brutal_kill) ->
 
    case monitor_child(Pid) of
    ok ->
        exit(Pid, kill),
        receive
        {'DOWN', _MRef, process, Pid, killed} ->
            ok;
        {'DOWN', _MRef, process, Pid, OtherReason} ->
            {error, OtherReason}
        end;
    {error, Reason} ->     
        {error, Reason}
    end;

shutdown(Pid, Time) ->
   
    case monitor_child(Pid) of
    ok ->
        exit(Pid, shutdown), %% Try to shutdown gracefully
        receive
        {'DOWN', _MRef, process, Pid, shutdown} ->
            ok;
        {'DOWN', _MRef, process, Pid, OtherReason} ->
            {error, OtherReason}
        after Time ->
            exit(Pid, kill),  %% Force termination.
            receive
            {'DOWN', _MRef, process, Pid, OtherReason} ->
                {error, OtherReason}
            end
        end;
    {error, Reason} ->     
        {error, Reason}
    end.

 

Ok，结束子进程时分情况处理了，先看看monitor_child/1，代码注释的比较详细，简单的说是用于处理child自己退出的情况。

monitor_child(Pid) ->
   
    %% Do the monitor operation first so that if the child dies
    %% before the monitoring is done causing a 'DOWN'-message with
    %% reason noproc, we will get the real reason in the 'EXIT'-message
    %% unless a naughty child has already done unlink…
    erlang:monitor(process, Pid),
    unlink(Pid),

    receive
    %% If the child dies before the unlik we must empty
    %% the mail-box of the 'EXIT'-message and the 'DOWN'-message.
    {'EXIT', Pid, Reason} ->
        receive
        {'DOWN', _, process, Pid, _} ->
            {error, Reason}
        end
    after 0 ->
        %% If a naughty child did unlink and the child dies before
        %% monitor the result will be that shutdown/2 receives a
        %% 'DOWN'-message with reason noproc.
        %% If the child should die after the unlink there
        %% will be a 'DOWN'-message with a correct reason
        %% that will be handled in shutdown/2.
        ok  
    end.

回头看shutdown/2，主要区别在于exit(Pid, Reason)这一行，如果子进程的shutdown策略为brutal_kill，则子进程被直接kill，而kill消息是不能被捕捉的，也就不存在terminate被调用的可能了（terminate能被调用是因为捕捉了{‘EXIT’,_, _}消息，详细情况请自行查看gen_server实现）。如果你想在退出时清理数据，这里一定不能设置为brutal_kill，而是设置为一个较大的时间数值（毫秒），用于等待子进程做善后工作：

exit(Pid, shutdown), %% Try to shutdown gracefully
        receive
        {'DOWN', _MRef, process, Pid, shutdown} ->
            ok;
        {'DOWN', _MRef, process, Pid, OtherReason} ->
            {error, OtherReason}
        after Time ->
            exit(Pid, kill),  %% Force termination.
            receive
            {'DOWN', _MRef, process, Pid, OtherReason} ->
                {error, OtherReason}
            end
如果在指定时间内，子进程尚未结束，则强制kill。

从这一块的源码中我们没有看到restart strategy(one_for_one …)对terminate的影响，这跟上面的测试结果不太吻合。过一遍supervisor的代码，发现针对simple_one_for_one和one_for_one的子进程的启动过程是不同的：

handle_call({start_child, EArgs}, _From, State) when ?is_simple(State) ->
    #child{mfa = {M, F, A}} = hd(State#state.children),
    Args = A ++ EArgs,
    case do_start_child_i(M, F, Args) of
    {ok, Pid} ->
        NState = State#state{dynamics =
                 ?DICT:store(Pid, Args, State#state.dynamics)},
        {reply, {ok, Pid}, NState};
    {ok, Pid, Extra} ->
        NState = State#state{dynamics =
                 ?DICT:store(Pid, Args, State#state.dynamics)},
        {reply, {ok, Pid, Extra}, NState};
    What ->
        {reply, What, State}
    end;

%%% The requests terminate_child, delete_child and restart_child are
%%% invalid for simple_one_for_one supervisors.
handle_call({_Req, _Data}, _From, State) when ?is_simple(State) ->
    {reply, {error, simple_one_for_one}, State};

handle_call({start_child, ChildSpec}, _From, State) ->
    case check_childspec(ChildSpec) of
    {ok, Child} ->
        {Resp, NState} = handle_start_child(Child, State),
        {reply, Resp, NState};
    What ->
        {reply, {error, What}, State}
    end;

simple_one_for_one形式启动的子进程根本没有放在supervisor的state.children里面，也就是说supervisor在terminate的时候根本没管simple_one_for_one形式启动的子进程，如此当supervisor结束时，所有的simple_one_for_one子进程都会收到一条{‘EXIT’, Pid, Reason}的消息，如果子进程有处理这样的消息并返回了stop，则会调用terminate。 但在执行terminate期间，app可能已经结束，从而正在停止中的系统会直接kill掉该进程（实际上是所有剩余的进程），使得其没有时间执行完所有的功能代码（参考之前的分析《init:stop浅析》）。

四、结论、问题与解决办法

1．  结论

2．  问题

使用simple_one_for_one时，在系统关闭时，可能无法正常的完成某些的善后工作，如数据持久等等

3．  解决办法

使用one_for_one，但是one_for_one的启动过程需要做一些简单的调整：

sup树的init返回：

  init([]) ->
    RestartStrategy = one_for_one,
    MaxRestarts = 1000,
    MaxSecondsBetweenRestarts = 3600,
    SupFlags = {RestartStrategy, MaxRestarts, MaxSecondsBetweenRestarts},
    {ok, {SupFlags, []}}.

start_child的时候childspec需要拼凑spec id：

supervisor:start_child(mod_stall_sup,
                       {lists:concat(["mod_stall_server_", MAPID]),
                        {mod_stall_server, start_link, [MAPID]},
                        transient, 30000, worker, [mod_stall_server]})   

日期：2010-08-03

boot之后关注的自然是stop，直接打开erts-5.7.5/src/init.erl源码看了看：

-spec stop() -> no_return().
stop() -> init ! {stop,stop}, ok.

{stop,Reason} ->
            stop(Reason,State);

最终的调用：

stop(Reason,State) ->
    BootPid = State#state.bootpid,
    {_,Progress} = State#state.status,
    State1 = State#state{status = {stopping, Progress}},
    clear_system(BootPid,State1),
    do_stop(Reason,State1).

看看 clear_system/2：

clear_system(BootPid,State) ->
    Heart = get_heart(State#state.kernel),
    shutdown_pids(Heart,BootPid,State),
    unload(Heart).
   
shutdown_pids(Heart,BootPid,State) ->
    Timer = shutdown_timer(State#state.flags),
    catch shutdown(State#state.kernel,BootPid,Timer,State),
    kill_all_pids(Heart), % Even the shutdown timer.
    kill_all_ports(Heart),
    flush_timout(Timer).
   
%%
%% Kill all existing pids in the system (except init and heart).
kill_all_pids(Heart) ->
    case get_pids(Heart) of
        [] ->
            ok;
        Pids ->
            kill_em(Pids),
            kill_all_pids(Heart)  % Continue until all are really killed.
    end.

kill_em([Pid|Pids]) ->
    exit(Pid,kill),
    kill_em(Pids);
kill_em([]) ->
    ok.

看到这里得到两个结论：

1． 除了kernel和init之外的所有的进程都是以kill的形式干掉的。注意这里的kernel是个list，包含多了pid

2． 先shutdown所有的kernel进程，后kill掉其他进程，最终halt。shutdown的形式则是一条EXIT消息

shutdown([{heart,_Pid}|Kernel],BootPid,Timer,State) ->
    shutdown(Kernel, BootPid, Timer, State);
shutdown([{_Name,Pid}|Kernel],BootPid,Timer,State) ->
    shutdown_kernel_pid(Pid, BootPid, Timer, State),
    shutdown(Kernel,BootPid,Timer,State);
shutdown(_,_,_,_) ->
    true.

%%
%% A kernel pid must handle the special case message
%% {'EXIT',Parent,Reason} and terminate upon it!
%%
shutdown_kernel_pid(Pid, BootPid, Timer, State) ->
    Pid ! {'EXIT',BootPid,shutdown},
    shutdown_loop(Pid, Timer, State, []).

发送EXIT消息，shutdown_loop/4等待结果。

根据上一篇分析的结果，application_controller是kernel pids的一员，查看application_controller的源码：

terminate(Reason, S) ->
    case application:get_env(kernel, shutdown_func) of
    {ok, {M, F}} ->
        catch M:F(Reason);
    _ ->
        ok
    end,
    foreach(fun({_AppName, Id}) when is_pid(Id) ->
            exit(Id, shutdown),
            receive
            {'EXIT', Id, _} -> ok
            end;
           (_) -> ok
        end,
        S#state.running),
ets:delete(ac_tab).

S#state.running中保存了所有已经在运行的application，对于每一个application，都以exit(Id, shutdown)形式让其退出，并一直等待。

到了这里不用继续看源码大致也能理清思路了，结论：

init:stop 

→  向所有kernel进程发送shutdown Exit消息

→ application 依次关闭子sup树（等待）

 → kill所有其他的非kernel进程

对于我们的app，一般都是最后启动，最先停止，如此，在停止我们的app的时候所有的系统服务都还是可用的（分布式、mnesia等等）。

目的：跟踪Erlang的启动过程

参考这里 http://erlangdisplay.javaeye.com/blog/315497 ，直接从erts-5.7.5/src/init.erl 的boot/1函数开始（关于这个链接给出的结论以后会继续研究分析）：

-spec boot([binary()]) -> no_return().
boot(BootArgs) ->
    register(init, self()),
    process_flag(trap_exit, true),
    start_on_load_handler_process(),
    {Start0,Flags,Args} = parse_boot_args(BootArgs),
    Start = map(fun prepare_run_args/1, Start0),
    Flags0 = flags_to_atoms_again(Flags),
    boot(Start,Flags0,Args).

do_boot(Init,Flags,Start) ->
    process_flag(trap_exit,true),
    {Pgm0,Nodes,Id,Path} = prim_load_flags(Flags),
    Root = b2s(get_flag('-root',Flags)),
    PathFls = path_flags(Flags),
    Pgm = b2s(Pgm0),
    _Pid = start_prim_loader(Init,b2a(Id),Pgm,bs2as(Nodes),
                 bs2ss(Path),PathFls),
    BootFile = bootfile(Flags,Root),
    BootList = get_boot(BootFile,Root),
    LoadMode = b2a(get_flag('-mode',Flags,false)),
    Deb = b2a(get_flag('-init_debug',Flags,false)),
    BootVars = get_flag_args('-boot_var',Flags),
    ParallelLoad =
    (Pgm =:= "efile") and (erlang:system_info(thread_pool_size) > 0),

    PathChoice = code_path_choice(),
    eval_script(BootList,Init,PathFls,{Root,BootVars},Path,
        {true,LoadMode,ParallelLoad},Deb,PathChoice),

    %% To help identifying Purify windows that pop up,
    %% print the node name into the Purify log.
    (catch erlang:system_info({purify, "Node: " ++ atom_to_list(node())})),

    start_em(Start).

boot/3的基本流程为 start_prim_loader/6 → eval_script/8 → start_em/1

1． start_prim_loader/6启动了erl_prim_loader模块，负责代码加载（远程或者本地等）

2． eval_script/8 负责启动一些关键的进程

来看个eval_script/8参数的例子：

{[{preLoaded,[erl_prim_loader,erlang,init,otp_ring0,

              prim_file,prim_inet,prim_zip,zlib]},

  {progress,preloaded},

  {path,["$ROOT/lib/kernel-2.13.5/ebin",

         "$ROOT/lib/stdlib-1.16.5/ebin"]},

  {primLoad,[error_handler]},

  {kernel_load_completed},

  {progress,kernel_load_completed},

  {path,["$ROOT/lib/kernel-2.13.5/ebin"]},

  {primLoad,[application,application_controller,

             application_master,application_starter,auth,code,

             code_server,disk_log,disk_log_1,disk_log_server,

             disk_log_sup,dist_ac,dist_util,erl_boot_server,erl_ddll,

             erl_distribution,erl_epmd,erl_reply|...]},

  {path,["$ROOT/lib/stdlib-1.16.5/ebin"]},

  {primLoad,[array,base64,beam_lib,c,calendar,dets,

             dets_server,dets_sup,dets_utils,dets_v8,dets_v9,dict,

             digraph,digraph_utils,edlin,edlin_expand|...]},

  {progress,modules_loaded},

  {path,["$ROOT/lib/kernel-2.13.5/ebin",

         "$ROOT/lib/stdlib-1.16.5/ebin"]},

  {kernelProcess,heart,{heart,start,[]}},

  {kernelProcess,error_logger,{error_logger,start_link,[]}},

  {kernelProcess,application_controller,

                 {application_controller,start,

                                         [{application,kernel,

                                                       [{description,[...]},{vsn,…},{…}|…]}]}},

  {progress,init_kernel_started},

  {apply,{application,load,

                      [{application,stdlib,[{description,...},{...}|...]}]}},

  {progress,applications_loaded},

  {apply,{application,start_boot,[kernel,permanent]}},

  {apply,{application,start_boot,[stdlib,permanent]}},

  {apply,{c,erlangrc,[]}},

  {progress,started}],

 <0.0.0>,

 {[],[]},

 {"/usr/local/lib/erlang",[]},

 false,

 {true,false,false},

 false,relaxed}

查看eval_script/8的实现（代码就不贴了），发现启动了上面参数中 kernelProcess对应键值的进程，如：

{kernelProcess,heart,{heart,start,[]}},

  {kernelProcess,error_logger,{error_logger,start_link,[]}},

  {kernelProcess,application_controller,

                 {application_controller,start,

                                         [{application,kernel,

eval_script([{kernelProcess,Server,{Mod,Fun,Args}}|CfgL],Init,
        PathFs,Vars,P,Ph,Deb,PathChoice) ->
    debug(Deb,{start,Server}),
    start_in_kernel(Server,Mod,Fun,Args,Init),
    eval_script(CfgL,Init,PathFs,Vars,P,Ph,Deb,PathChoice);

start_in_kernel(Server,Mod,Fun,Args,Init) ->
    Res = apply(Mod,Fun,Args),
    Init ! {self(),started,{Server,Res}},
    receive
    {Init,ok,Pid} ->
        unlink(Pid),  %% Just for sure…
        ok;
    {Init,ignore} ->
        ignore
    end.

最终产生一条消息给init：

Init ! {self(),started,{Server,Res}},

{BootPid,started,KernelPid} ->

        boot_loop(BootPid, new_kernelpid(KernelPid, BootPid, State));

init收到消息后，就将该进程加入到kernel pids的队列中了。

new_kernelpid({Name,{ok,Pid}},BootPid,State) when is_pid(Pid) ->
    link(Pid),
    BootPid ! {self(),ok,Pid},
    Kernel = State#state.kernel,
    State#state{kernel = [{Name,Pid}|Kernel]};
new_kernelpid({_Name,ignore},BootPid,State) ->
    BootPid ! {self(),ignore},
    State;
new_kernelpid({Name,What},BootPid,State) ->
    erlang:display({"could not start kernel pid",Name,What}),
    clear_system(BootPid,State),
    crash("could not start kernel pid", [Name, What]).

{kernelProcess,application_controller,

                 {application_controller,start,

                                         [{application,kernel,

application_controller启动后会启动kernel app，至此erlang的启动过程就大致的有个了解了，而关于application的启动过程就不在本次分析范围之内了。

结论：

系统从init<0.0.0>开始，一些关键的进程如：error_logger、application_controller、erl_prim_load等都会预先启动并加入到kernel pids中。

附言：

本次跟踪自然又离不开余锋老大(http://blog.yufeng.info/ )的指点，init.erl是preloaded模块：

{preLoaded,[erl_prim_loader,erlang,init,otp_ring0,

              prim_file,prim_inet,prim_zip,zlib]},

而由于本文之前的无知，导致我去尝试修改init.erl。 如果大家需要跟踪init.erl的启动细节，需要修改源码包中的 erts/preloaded/src/init.erl、make && make install，由于此时系统还没跑起来，所以error_logger io之类的模块是没有用的，幸运的是preloaded里面有 prim_file，可以通过 prim_file:write_file/2把一些状态写入到文件中以便查看。

-rw-r–r– 1 root root 183741 2010-05-21 11:43 erlang.el

-rw-r–r– 1 root root  10059 2010-05-21 11:43 erlang-eunit.el

-rw-r–r– 1 root root   3452 2010-05-21 11:43 erlang-start.el

-rw-r–r– 1 root root   1611 2010-05-21 11:43 README

-rw-r–r– 1 root root  12834 2010-05-21 11:43 test.erl.indented

-rw-r–r– 1 root root  11877 2010-05-21 11:43 test.erl.orig

上代码：

-module(mnesia_read_test).

-export([start/0, init_data/0, start2/0]).

-record(r_test, {id, name}).

start() ->

        statistics(wall_clock),

    statistics(runtime),

        read(),

        {_, Time1} = statistics(wall_clock),

    {_, Time2} = statistics(runtime),

    io:format("times:~p, wall_clock ~p, runtime:~p", [100000, Time1, Time2]).

start2() ->

        statistics(wall_clock),

    statistics(runtime),

        read2(),

        {_, Time1} = statistics(wall_clock),

    {_, Time2} = statistics(runtime),

    io:format("times:~p, wall_clock ~p, runtime:~p", [100000, Time1, Time2]).

read() ->

        dirty_read(100000).

dirty_read(0) ->

    ok;

dirty_read(N) ->

    mnesia:dirty_read(r_test, N),

    dirty_read(N-1).

read2() ->

        t_read(100000).

t_read(0) ->

        ok;

t_read(N) ->

        mnesia:transaction( fun() -> mnesia:read(r_test, N) end),

        t_read(N-1).

init_data() ->

    mnesia:stop(),

    mnesia:create_schema([node()]),

    mnesia:start(),

    mnesia:create_table(r_test, [

                               {attributes, record_info(fields, r_test)},

                               {record_name, r_test},

                               {disc_copies, [node()]}

                               ]),

    mnesia:transaction(

        fun() ->

            t_write(10000)

        end

    ).

t_write(0) ->

    ok;

t_write(N) ->

    Name = lists:append(["name_", N]),

    R = #r_test{id=N, name=Name},

    mnesia:write(R),

    t_write(N-1).

两种情况都循环读了10W次，连续测试10次，机器配置为：

Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz      2*4核

12G内存

事务读测试结果：

times:100000, wall_clock 4168, runtime:4160ok

times:100000, wall_clock 4296, runtime:4250ok

times:100000, wall_clock 4338, runtime:4290ok

times:100000, wall_clock 4310, runtime:4260ok

times:100000, wall_clock 4330, runtime:4280ok

times:100000, wall_clock 4342, runtime:4270ok

times:100000, wall_clock 4399, runtime:4310ok

times:100000, wall_clock 4366, runtime:4310ok

times:100000, wall_clock 4378, runtime:4310ok

times:100000, wall_clock 4429, runtime:4330ok

一次读的时间大于为44us，这还是在没有分布式的情况下的测试结果，如果是在分布式环境中，由于网络IO和远程加锁，性能会更差。

脏读测试结果：

times:100000, wall_clock 128, runtime:130ok

times:100000, wall_clock 126, runtime:120ok

times:100000, wall_clock 124, runtime:120ok

times:100000, wall_clock 126, runtime:120ok

times:100000, wall_clock 127, runtime:130ok

times:100000, wall_clock 125, runtime:130ok

times:100000, wall_clock 125, runtime:120ok

times:100000, wall_clock 127, runtime:120ok

times:100000, wall_clock 128, runtime:130ok

times:100000, wall_clock 127, runtime:130ok

和ets的性能几乎一样，一次读取的消耗大约1.2us，和事务相比快了几十倍。追踪脏读源码到mnesia_lib.erl中：

db_get(Tab, Key) ->

    db_get(val({Tab, storage_type}), Tab, Key).

db_get(ram_copies, Tab, Key) -> ?ets_lookup(Tab, Key);

db_get(disc_copies, Tab, Key) -> ?ets_lookup(Tab, Key);

db_get(disc_only_copies, Tab, Key) -> dets:lookup(Tab, Key).

呵呵，果然是ets直接操作。

(最近挺忙，都没时间写点啥)

gen_server是OTP中的一个重要组成，在开发中出现的频率相当高。弄明白这一块的，对于gen_server的使用有着相当好的帮忙。下面多数为代码。

从start_link开始：

gen_server.erl

start_link(Name, Mod, Args, Options) ->

gen:start(?MODULE, link, Name, Mod, Args, Options).

跳到gen.erl，这里的GenMod值为gen_server，LinkP为link

start(GenMod, LinkP, Name, Mod, Args, Options) ->

    case where(Name) of

undefined ->

    do_spawn(GenMod, LinkP, Name, Mod, Args, Options);

Pid ->

    {error, {already_started, Pid}}

end.

再跳：

do_spawn(GenMod, link, Name, Mod, Args, Options) ->

    Time = timeout(Options),

    proc_lib:start_link(?MODULE, init_it,

[GenMod, self(), self(), Name, Mod, Args, Options],

Time,

spawn_opts(Options));

跳到proc_lib.erl文件：

start_link(M,F,A,Timeout,SpawnOpts) when is_atom(M), is_atom(F), is_list(A) ->

    Pid = ?MODULE:spawn_opt(M, F, A, ensure_link(SpawnOpts)),

sync_wait(Pid, Timeout).

注意这里有个等待返回，之后需要proc_lib:init_ack来返回消息。

spawn_opt(M, F, A, Opts) when is_atom(M), is_atom(F), is_list(A) ->

    Parent = get_my_name(),

    Ancestors = get_ancestors(),

    check_for_monitor(Opts),

    erlang:spawn_opt(?MODULE, init_p, [Parent,Ancestors,M,F,A], Opts).

这里调用proc_lib模块的init_p方法：

-spec init_p(pid(), [pid()], function()) -> term().

init_p(Parent, Ancestors, Fun) when is_function(Fun) ->

    put('$ancestors', [Parent|Ancestors]),

    {module,Mod} = erlang:fun_info(Fun, module),

    {name,Name} = erlang:fun_info(Fun, name),

    {arity,Arity} = erlang:fun_info(Fun, arity),

    put('$initial_call', {Mod,Name,Arity}),

    try

Fun()

    catch

Class:Reason ->

    exit_p(Class, Reason)

    end.

-spec init_p(pid(), [pid()], atom(), atom(), [term()]) -> term().

init_p(Parent, Ancestors, M, F, A) when is_atom(M), is_atom(F), is_list(A) ->

    put('$ancestors', [Parent|Ancestors]),

    put('$initial_call', trans_init(M, F, A)),

    init_p_do_apply(M, F, A).

init_p_do_apply(M, F, A) ->

    try

apply(M, F, A) 

    catch

Class:Reason ->

    exit_p(Class, Reason)

end.

有点晕头了吧，MFA是什么呢？如下：

gen, init_it,

[gen_server, self(), self(), Name, Mod, Args, Options]

这里的Name, Mod, Args是我们自己的注册名，模块名、参数。

调回init：

init_it(GenMod, Starter, Parent, Name, Mod, Args, Options) ->

    case name_register(Name) of

true ->

    init_it2(GenMod, Starter, Parent, Name, Mod, Args, Options);

{false, Pid} ->

    proc_lib:init_ack(Starter, {error, {already_started, Pid}})

    end.

init_it2(GenMod, Starter, Parent, Name, Mod, Args, Options) ->

    GenMod:init_it(Starter, Parent, Name, Mod, Args, Options).

ok，又回到gen_server了。跳转到gen_server的init_it：

init_it(Starter, self, Name, Mod, Args, Options) ->

    init_it(Starter, self(), Name, Mod, Args, Options);

init_it(Starter, Parent, Name0, Mod, Args, Options) ->

    Name = name(Name0),

    Debug = debug_options(Name, Options),

    case catch Mod:init(Args) of

{ok, State} ->

    proc_lib:init_ack(Starter, {ok, self()}),      

    loop(Parent, Name, State, Mod, infinity, Debug);

{ok, State, Timeout} ->

    proc_lib:init_ack(Starter, {ok, self()}),      

    loop(Parent, Name, State, Mod, Timeout, Debug);

{stop, Reason} ->

    %% For consistency, we must make sure that the

    %% registered name (if any) is unregistered before

    %% the parent process is notified about the failure.

    %% (Otherwise, the parent process could get

    %% an 'already_started' error if it immediately

    %% tried starting the process again.)

    unregister_name(Name0),

    proc_lib:init_ack(Starter, {error, Reason}),

    exit(Reason);

ignore ->

    unregister_name(Name0),

    proc_lib:init_ack(Starter, ignore),

    exit(normal);

{'EXIT', Reason} ->

    unregister_name(Name0),

    proc_lib:init_ack(Starter, {error, Reason}),

    exit(Reason);

Else ->

    Error = {bad_return_value, Else},

    proc_lib:init_ack(Starter, {error, Error}),

    exit(Error)

end.

呵呵，苦尽甘来，终于来到loop主循环了。 gen_server的消息怎么来的？就是这个loop不断地取出消息、decode_msg、再loop来不断从消息队列中取出消息的。这个主循环就是我们的gen_server进程了。

loop(Parent, Name, State, Mod, hibernate, Debug) ->

    proc_lib:hibernate(?MODULE,wake_hib,[Parent, Name, State, Mod, Debug]);

loop(Parent, Name, State, Mod, Time, Debug) ->

    Msg = receive

      Input ->

    Input

  after Time ->

  timeout

  end,

    decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, false).

decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, Hib) ->

    case Msg of

{system, From, Req} ->

    sys:handle_system_msg(Req, From, Parent, ?MODULE, Debug,

  [Name, State, Mod, Time], Hib);

{'EXIT', Parent, Reason} ->

    terminate(Reason, Name, Msg, Mod, State, Debug);

_Msg when Debug =:= [] ->

    handle_msg(Msg, Parent, Name, State, Mod);

_Msg ->

    Debug1 = sys:handle_debug(Debug, {?MODULE, print_event}, 

      Name, {in, Msg}),

    handle_msg(Msg, Parent, Name, State, Mod, Debug1)

    end.

这里我们就看到了terminate的自动回调（如果设置了trap_exit）。

handle_msg中处理了handle_call类型的调用， 而handle_cast和handle_info则由dispatch来处理：

dispatch({'$gen_cast', Msg}, Mod, State) ->

    Mod:handle_cast(Msg, State);

dispatch(Info, Mod, State) ->

Mod:handle_info(Info, State).

handle_msg处理handle_call也很简单，回调我们的handle_call方法：

handle_msg({'$gen_call', From, Msg}, Parent, Name, State, Mod, Debug) ->

case catch Mod:handle_call(Msg, From, State) of

……

至此，整个gen_server的运行流程就清楚了（晕的话，多看几遍）。

回头再来看看terminate的处理

terminate(Reason, Name, Msg, Mod, State, Debug) ->

    case catch Mod:terminate(Reason, State) of

{'EXIT', R} ->

    error_info(R, Name, Msg, State, Debug),

    exit(R);

_ ->

    case Reason of

normal ->

    exit(normal);

shutdown ->

    exit(shutdown);

{shutdown,_}=Shutdown ->

    exit(Shutdown);

_ ->

    error_info(Reason, Name, Msg, State, Debug),

    exit(Reason)

    end

end.

这里terminate在回调了gen_server的terminate函数后，又exit了一次，目的是为了产生一个'EXIT'消息给supervisor，以便让supervisor做相应的重启策略。