Archive for 七月 2011

shared_ptr真能防止内存泄漏吗?

这个命题有些诡异,因为shared_ptr设计的初衷就是为了防止内存泄漏,但是先别急,等我把问题描述清楚.

事出缘由是这几天项目出现一个内存泄漏的bug,之前这部分是使用shared_ptr封装了很多指针的操作,后来出于效率的考虑,改回了裸指针.由于我们使用的google

全局定义结构体名称冲突导致的问题(C++)

上周项目代码中出现一个诡异的问题,我在某个数据结构中新增了一个string类型的成员变量,但是每次到了赋值的时候必然出现core dump.跟踪了好久,也猜想到应该是string的函数指针表之类的被破坏了,但是始终找不到原因.最后突然想到搜索代码中该结构体定义的地方,发现同时有两个.cc文件中都定义了该名字的结构体(其中一个也是这一次新增的),于是恍然大悟,应该是结构体的定义名称冲突导致的.

我将这段出错的代码,抽取出来写了个demo,放在

erlang中使用ets的一个弱问题

这几天纠结在一个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中使用google protobuf进行通信

初学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)