Final Blog

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

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

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