继续接着上一篇文章分析gen.erl来分析下gen_server.
在gen.erl中,start操作最终会走到GenMod:init_it函数中,这里的GenMod就是gen_server/fsm/event三个模块,所以先来看看gen_server中的init_it函数.
%%% --------------------------------------------------- %%% Initiate the new process. %%% Register the name using the Rfunc function %%% Calls the Mod:init/Args function. %%% Finally an acknowledge is sent to Parent and the main %%% loop is entered. %%%
gen系列代码,gen_server,gen_event,gen_fsm的代码都在erlang代码的lib/stdlib中,它们都是以gen.erl为基础的.gen.erl中定义了一些这几个behavior公有的代码,所以首先来看看gen.erl做了什么.
gen.erl中主要是定义了以下几个操作:start(启动一个gen系列的服务器),call(向gen系列服务器send请求并且等待回复).
1) start
start(GenMod, LinkP, Mod, Args, Options) ->
do_spawn(GenMod, LinkP, Mod, Args, Options).
do_spawn(GenMod, _, Name, Mod, Args, Options) ->
Time = timeout(Options),
erlang中可以自定义behaviour,但是如果一个模块是实现了该自定义behaviour的话,那么首先要编译behaviour,其次在编译该模块时加入-pa指定编译好的behaviour.beam路径,否则编译的时候会提示该behaviour未定义.
换句话说,实现需要依赖到behaviour模块编译.
因此需要根据代码中的这种依赖关系,对代码进行一次梳理,定义一个正确的编译顺序.幸而rabbitmq项目已经有这样的代码,我就抽取出来用了,具体的实现还没有细看.在这个框架的文件组织中,erl文件放在src子目录下面,在src/Makefile中,首先以当前目录的所有erl文件为参数调用../generate_deps(这个文件取自rabbitmq项目)来产生依赖关系文件deps.mk,注意要在Makefile中include这个文件,这样新的依赖关系才会起效,然后编译会自动根据新的依赖关系来安排编译的顺序了.有了这些,你所需要做的就是把你写的erl文件放在src目录下面,依赖关系什么的,由Makefie搞定了.
示例项目在
阅读过zmq的代码之后,感觉这个网络层是我目前见过最高效的–线程之间使用lockfree的消息队列保存消息,可以启动多个I/O线程分担压力等等特性.于是决定基于它写一个protobuf
传说rabbitmq网络层实现的优雅高效,于是我就尝试着将其中的网络层抽取出来,模拟着做了一个echo服务器,代码放在
这个命题有些诡异,因为shared_ptr设计的初衷就是为了防止内存泄漏,但是先别急,等我把问题描述清楚.
事出缘由是这几天项目出现一个内存泄漏的bug,之前这部分是使用shared_ptr封装了很多指针的操作,后来出于效率的考虑,改回了裸指针.由于我们使用的google
上周项目代码中出现一个诡异的问题,我在某个数据结构中新增了一个string类型的成员变量,但是每次到了赋值的时候必然出现core dump.跟踪了好久,也猜想到应该是string的函数指针表之类的被破坏了,但是始终找不到原因.最后突然想到搜索代码中该结构体定义的地方,发现同时有两个.cc文件中都定义了该名字的结构体(其中一个也是这一次新增的),于是恍然大悟,应该是结构体的定义名称冲突导致的.
我将这段出错的代码,抽取出来写了个demo,放在
这几天纠结在一个erlang的ets操作问题上,最后才发现,其实是一个很弱的问题.
问题大致是这样的:程序启动之后,读取配置文件,将其中的配置保存到ets表中,然后创建superviser监控进程,再由这个进程拉起几个工作进程,工作进程中会根据情况通过之前创建的保存配置的ets表获取一些配置进行操作.可就是在work操作ets表的过程中,偶尔会有出现报错,大意是这个ets表是无效的,未定义的.查了一些ets的资料,起初以为问题在于表的时候没有设置属性为public所致,但是还是出现问题.
找了很多地方无果,最后想起之前有同事提过公司内有玩erlang比较熟悉的人,遂赶紧将出错的代码提炼出来求教.问题出在于,这个ets表是在程序开始之后马上创建的,而后这个进程又创建了superviser进程等,而在这个过程完结了之后,这个最初的进程就退出了,于是由它创建的ets表也就失效了.因此,偶有出现访问异常的原因,实际上跟erlang虚拟机的进程调度相关(一般这些灵异的问题都跟这些有关系).因此解决的办法是,在superviser进程中创建ets表,由于这个进程一直常驻,所以就不会由于它的退出导致访问异常了.
不过,话说回来,我的这个思路还是不那么COP的编程思路.更好的做法是,给这个ets表包一个gen_server的访问层,对这个表的访问,操作等都通过gen_server的回调函数handle_call/handle_cast等来进行,也就是对这个表的操作局限在这个进程中,其他进程如果要访问还是走的erlang惯用的消息通信的方式.而之前的方式,虽然也可以,但是必然会造成大量的对ets表的加解锁同步问题.
初学erlang,花了不少的功夫,想要在erlang中集成google的protobuf用于消息通信.个人觉得,使用类似protobuf这样通用的编解码模块,有一个好处就是这部分完全交给别人,再不用自己关心什么很操蛋的大小端,数据长度等琐碎的问题,另外,protobuf使用.proto文件自描述协议,C/S端人员可以通过这个来讨论问题,一目了然.
然而,要把它集成到erlang中还是一件比较麻烦的事情,一来google官方没有对erlang进行支持,这也许是因为google官方认定的编程语言只有C++,java,Python三种的缘故吧,而它的竞争对手,如thrift等都提供了erlang的支持.虽然官网上给出了第三方做的其他语言的实现,但是毕竟不是官方的实现,可能会有些未知的问题.比如我很担心我使用erlang非官方的protobuf实现写了一个服务器,但是再用比如python写了一个客户端,C/S两端都使用protobuf进行通信,但是由于编解码实现的差异,导致了协议数据有出入.
不过,鉴于我在搜索资料的时候未发现比较好的介绍如何在erlang中使用protobuf的方式,还是记录一下吧.
1)