Year: 2011

好吧, 看到标题你一定认为我犯了一个big mistake, 我没有遵循include .h标准范式去编写程序, 不过我还是想说说这里面的好处 :) 现在我们有一个需求, 想要编写一套事件库以便适应不同的平台(linux, freebsd … ), OK, 这里有一个显然的问题是我们需要一套抽象接口, 以便不同的平台都去遵循使用它们, 在不同平台下编译可以使用相应的.c文件, 我们需要建立抽象接口头文件, 但是如何去找到不同的实现文件那? 因为不同的实现文件需要在编译期指定好, 写在Makefile里做参数? 显然不够智能, 我们还是希望可以auto build. 于是我们想出了一套看似完美的方案, 为不同平台建立不同命名的头文件, 比如linux下使用 ev_epoll.h, freebsd下使用ev_kqueue.h, 不过这两个文件内部使用完全相同的接口定义, 一般来讲这没什么问题, 我们只需要在framework里根据不同平台include不同的header即可~ . 不过这里有个潜在的问题, 我们一旦修改了抽象接口定义, 不但要修改响应实现文件(这不可避免), 还需要级联的维护响应的headers, 这看起来很糟糕, 然后聪明的我们又想出来一个升级方案, 在这些不同平台的headers里面统一include一个global header(包含抽象描述), 我们拿着这套方案感觉很nice~ , 不过我们一旦修改, 仍然不可避免的去要修改global header, 虽然代价已经很小了~ :D 好了, 赘赘的说了一大堆, 开始进入正题, 我们能不能有什么办法去掉这个header, 因为这个header本质上没有存在的价值, 外部并需要看到他, 多个它放在那会让使用者头大不已, 请出我们今天主角:”include … Read more

整理了一下之前自己写的库. 地址在 https://github.com/finaldie/final_libs 有兴趣的同学可以自取 :) 有什么建议可以mail给我(hyzwowtools@gmail.com or hyzwowtools@163.com) libs contain: 1. a fifo list ( lockfree in one production one consumer ) 2. hash table 3. mutex ( wrap system lock ) 4. log ( asynchronous log, aio not recommand use ) 5. memory buff ( a light-weight buff ) 6. read conf 7. timer 8. thread cache … Read more

自己之前写了一个网络库, 最初仅仅是为了练手, 后来用着还算顺手, 就直接用在自己的小项目里了, 不过最近查看libev和redis的代码, 自己反思了下, 得到了一些总结一些经验 :) 之前在写这部分的时候, 直接把epoll的代码耦合在网络库里了, 也没觉得不妥, 也会经常的出现一些疑惑, 老是不能特别专注在网络buff, 异常处理部分, 反而总是在epoll事件上面弄来弄去的. 现在发现这是个big mistake, epoll应该被剥离出来, 单独成库, 像libev一样的独立事件库, 没有任何其他功能, 而network部分应当在此基础上利用其接口进行编写, 从而简化编程. 常言道, 出来混, 迟早是要还的, 所以这部分还需要我继续重构下~ :D, 将这两部分完全剥离开. keep fighting!~