Monthly Archives: November 2011

7 posts

How to Make a AutoBuild System with Git Server

今天给大家分享一下最近自己的成果, 折腾了一个autobuild系统, 如果您和我有同样的需求, 不妨跟随我一起搭建一个这样的系统, easy and simple, have fun 🙂 Why:   事情是这样开始的, 我自己的项目放置在github上, 这是一个linux项目, 然而我所用来开发的机器是mac, 它不能用来编译所有的模块, 每次我都需要push提交之后, 再去server上pull下来, 然后编译看看结果, 这个过程我持续了一阵子之后再也忍受不了了, 我想要一个这样的系统: 1. 当我push提交之后, 他能实时的反馈给我编译的结果, 就像本地编译一样 2. 运行test unit, 并将结果实时反馈给我 3. 随后发送一封邮件到我的邮箱内, 包含编译结果以及test unit运行结果 4. 而这次的提交仅仅是为了测试集成的效果, 而不影响真正的版本库主干 How:   目的明确后, 我想到了git hook, 这里面的hook有一个可以满足我的需求– post-receive, 这是一个server端的hook(shell脚本), 每当接收到applypatch后都会调用一次并将输出结果反馈给client, 接下来我们将开始利用这个hook搭建这套系统. 首先我们来看一下工作流程(如下图): 图1 WorkFlow 简单的描述一下这个流程, 相对还算清晰简洁, 找一台可以用作build的机器, 建立一个git bare repo […]

Include C file

好吧, 看到标题你一定认为我犯了一个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, 虽然代价已经很小了~ 😀 好了, 赘赘的说了一大堆, 开始进入正题, […]

整理下自己写的常用库

整理了一下之前自己写的库. 地址在 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 […]

event & network 设计思考

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

依旧怀念下 :D

在校期间玩WOW留下的回忆 😀 每每看着 都觉得热血沸腾! That’s blood! Fight! 每每低落的时候看一遍都能激励我再次走出迷茫 加油 小F!

多线程异常处理之内存泄漏

 OK, 我们熟知, 多线程编程已经必需品, 但是还是要切忌的提醒一下, 首先要clear your mind, 不要滥用.  想必大家都碰到过一些情况, 比如来了一个请求, 此时被dispatch到一个具体的工作线程, 不过悲剧的是我们并没有很好的处理好异常, 导致了不可预期的错误, 此时一方面我们要丢弃该请求返回一个错误码, 此外我们还需要清理刚刚申请过的内存, 所以这里就有问题了, 如何知道我都申请了哪些内存… 这的确是一个头疼的问题. 通常我们会有几种解决方案: 1. 像apache一样多进程, 一旦遇到不可解决的错误并造成严重的内存泄漏, 我们可以简单的kill掉进程然后重新启动一个即可, 因为操作系统会帮我们清理掉所有内存. 2. 工作线程在执行具体逻辑任务的时候使用嵌入式脚本来负责处理, 比如lua这种, 所以我们不用担心会有内存泄漏, 也不用担心会crash掉. 如果你既不想开进程, 也不想使用脚本, 那么接下来就是我这次要讨论的话题了, 如何让线程轻松的回收掉”泄漏”的内存. Why 我们不用前两种? 多进程模型已经很成熟, 脚本也很简单 为何不用? 其实很多时候我们不想再让消息通过tcp传递给别人, 因为进程内部的传递很方便, 而且我们要在全局共享一些状态, 如果分为多进程又很不好共享. OK, 看来需求很明确, 所以我们要好好想想这个解决方案, 目前来看, 我想到的是在每个线程上搭载一个mempool, 每个线程内部使用这个独立的mempool进行分配内存, 一旦遇到不可挽回的错误, 可以回收掉mempool以便清理掉所有分配的内存. […]