第二章的时候,我们已经接触过sys模块了,现在我们来进一步看一下源码的实现.
我们还是用回第二章的例子:
1 | -module(sync_code_reload). |
先从进程启动的位置开始切入:
gen_server.erl:
1 | start_link(Mod, Args, Options) -> |
进入gen模块最后会回调本模块的init_it方法:
1 | init_it(Starter, self, Name, Mod, Args, Options) -> |
进入init_it之后会调用回调模块的init方法回去初始状态,然后进入loop:
1 | loop(Parent, Name, State, Mod, hibernate, Debug) -> |
接受到系统消息{system, From, Req}会调用sys:handle_system_msg方法处理,如果是普通消息会进入handle_msg处理,处理完普通消息最后会回到loop,现在我们来看看sys:suspend/1 做了什么:
1 | suspend(Name) -> send_system_msg(Name, suspend). %% 发送一个系统消息到进程 |
就是发送一个系统消息给进程,通过之前的分析,我们知道gen_server处理系统消息是通过调用sys:handle_system_msg方法来处理的,直接看调用sys:handle_system_msg方法:
1 | handle_system_msg(Msg, From, Parent, Mod, Debug, Misc, Hib) -> |
进入do_cmd:
1 | do_cmd(_, suspend, _Parent, _Mod, Debug, Misc) -> |
返回一个状态suspended:然后进入suspend_loop:
1 | %% 进入 suspend_loop 之后就停留在receive上,只处理系统消息和异常,不再处理其他消息也就是暂停处理其他消息了 |
从源代码中我们可以看到 sys:suspend/1 的主要认为就是从gen_server:loop转换到sys:suspend_loop ,而这个方法只处理了系统消息和异常退出消息,其他消息是不出理的,其他消息会留在邮箱里,这也就完成了暂停了.
这时候我们应该执行加载新代码模块进入vm:l(sync_code_reload).;然后再调用sys:change_code/4 通知到进程去回调模块的code_change方法对内部状态做相应的改变:
sys.erl:
1 | change_code(Name, Mod, Vsn, Extra) -> %% 仍然是发送系统消息 |
在处理change_code的时候会先调用gen_server:system_code_change/4:
1 | system_code_change([Name, State, Mod, Time], _Module, OldVsn, Extra) -> |
%% 用之前的例子来说这里 Mod=sync_code_reload
执行完code_change之后我们获得了新的内部状态,这样就避免了与新代码的冲突了,最后需要恢复一下进程,然后正常处理消息,调用sys:resume:
1 | resume(Name) -> send_system_msg(Name, resume). %% 同样是发送系统消息 |
恢复状态为running后,会回调gen_server:system_continue方法:
1 | system_continue(Parent, Debug, [Name, State, Mod, Time]) -> %% 回调 |
这个方法主要做的是带着新的state进入loop,进入loop之后会正常的接受和处理消息.
总结:
我们可以看到sys的暂停只是将进程的处理方法从gen_server的loop的接受并处理全部消息切换到sys:suspend_loop方法,只处理系统消息,其他都不处理;这样也确保了在加载新代码之后到执行变更进程内部状态这段时间内不会收到其他消息,这样也不会造成因为代码的版本不同,内部状态数据格式不对而异常退出这样的事情发送了.