rpc:call/4函數解析

最近據說erlang的rpc跟其餘語言的rpc模式不是很相同，因此就開始學習rpc模塊的方法，如下是rpc:call/4函數的一些解析。

rpc:call/4函數體：

call(N,M,F,A) when node() =:= N ->  %% Optimize local call
    local_call(M, F, A);
call(N,M,F,A) ->
    do_call(N, {call,M,F,A,group_leader()}, infinity).

這裏會判斷是不是在當前節點內運行。若是是的話，咱們接着往下看：

local_call(M, F, A) when is_atom(M), is_atom(F), is_list(A) ->
    case catch apply(M, F, A) of
	{'EXIT',_}=V -> {badrpc, V};
	Other -> Other
    end.

則直接調用apply方法，獲得結果。

若是不是當前節點：

do_call(Node, Request, infinity) ->
    rpc_check(catch gen_server:call({?NAME,Node}, Request, infinity));
do_call(Node, Request, Timeout) ->
    Tag = make_ref(),
    {Receiver,Mref} =
	erlang:spawn_monitor(
	  fun() ->
		  %% Middleman process. Should be unsensitive to regular
		  %% exit signals.
		  process_flag(trap_exit, true),
		  Result = gen_server:call({?NAME,Node}, Request, Timeout),
		  exit({self(),Tag,Result})
	  end),
    receive
	{'DOWN',Mref,_,_,{Receiver,Tag,Result}} ->
	    rpc_check(Result);
	{'DOWN',Mref,_,_,Reason} ->
	    %% The middleman code failed. Or someone did 
	    %% exit(_, kill) on the middleman process => Reason==killed
	    rpc_check_t({'EXIT',Reason})
    end.

rpc_check({'EXIT', {{nodedown,_},_}}) ->
    {badrpc, nodedown};
rpc_check({'EXIT', _}=Exit) ->
    %% Should only happen if the rex process on the other node
    %% died.
    {badrpc, Exit};
rpc_check(X) -> X.

這裏會另外啓動一個進程處理rpc要處理的內容，使用gen_server:call/3方法。要注意，這裏有超時狀況的考慮，若是是infinity則永遠等待；若是是Timeout時間，則spawn_monitor新進程，關注新進程的返回值。經過exit/1來返回值，這裏也是一種比較特別的返回值的方式。爲何2個超時時間不一樣而採起不一樣的處理方式，這裏面不是很明白。翻看了一下gen_server:call/4的實現代碼，對不一樣的timeout進行相同的處理，這裏看起來有些冗餘。最後全部的方法都要檢查返回值。

gen_server:call/3方法調用{?NAME, Node}進程來處理，咱們能夠看到rpc.erl就是一個gen_server實現的模塊，rpc模塊啓動的進程名稱就是?NAME.

-define(NAME, rex).

-behaviour(gen_server).


start() ->
    gen_server:start({local,?NAME}, ?MODULE, [], []).

start_link() ->
    gen_server:start_link({local,?NAME}, ?MODULE, [], []).

接下來，咱們看handle_call處理：

handle_call({call, Mod, Fun, Args, Gleader}, To, S) ->
    handle_call_call(Mod, Fun, Args, Gleader, To, S);


handle_call_call(Mod, Fun, Args, Gleader, To, S) ->
    %% Spawn not to block the rpc server.
    {Caller,_} =
	erlang:spawn_monitor(
	  fun () ->
		  set_group_leader(Gleader),
		  Reply = 
		      %% in case some sucker rex'es 
		      %% something that throws
		      case catch apply(Mod, Fun, Args) of
			  {'EXIT', _} = Exit ->
			      {badrpc, Exit};
			  Result ->
			      Result
		      end,
		  gen_server:reply(To, Reply)
	  end),
    {noreply, maps:put(Caller, To, S)}.

爲了避免阻塞rpc這個進程的運行，新spawn_monitor啓動一個進程處理。這裏要設置group_leader，主要是把io輸出給集中到一塊兒，這個能夠另外參考：

[Erlang 0041] 詳解io:format

group_leader的設計和用途

這裏新啓動的進程崩潰掉，rpc進程會收到通知：

handle_info({'DOWN', _, process, Caller, normal}, S) ->
    {noreply, maps:remove(Caller, S)};
handle_info({'DOWN', _, process, Caller, Reason}, S) ->
    case maps:get(Caller, S, undefined) of
	undefined ->
	    {noreply, S};
	{_, _} = To ->
	    gen_server:reply(To, {badrpc, {'EXIT', Reason}}),
	    {noreply, maps:remove(Caller, S)}
    end;

確保前面調用rpc:call/4的進程能收到返回錯誤的信息。

總的來講，rpc:call/4的操做就是，若是是本節點內的rpc操做，則直接運行；若是不是本節點，則發送要運行的命令指令到指定的節點中的?NAME進程進行處理。？NAME進程基於不阻塞的考慮，會另外啓動新進程進行處理。但總的來講，若是rpc:call/4操做很頻繁的話，仍是會出現？NAME進程響應不過來的狀況，存在單點故障的狀況。