Python游戏服务器开发日记（七） 关于协程(greenlet)和C语言的思考

        前两周埋头在服务器的具体技术试验里，不断的遇到小问题，不断的解决。

        大量的问题核心就是在利用dlfcn库调用python so时，API的用法会有变化。导出符号本身不是什么难题，难在某些Python C API是用宏或者其他方式提供的。最奇葩的是greenlet库，把所有API放在一个全局指针数组里，而且初始化方法也和标准python扩展库不甚相同。后来是采取把greenlet库直接和python so编译在一起，然后又把全局指针数组折腾一番才搞定。

        总结一下，第一个问题——对C语言还是不熟。对C的标准库不熟，对C的惯用技巧和模式不熟。这两天在知乎上看了大量C++的批评文章，包括韦易笑的几篇文章，和云风几年前告别C++时写的文章。时至今日，读来感触颇深。打算在模块化设计上继续深造，同时学习CPython、skynet等等高质量的纯C项目，把C语言用好。

        第二个问题，考虑coroutine的封装时，真是头绪纷乱繁多，skynet对coroutine的封装愣是没看懂（可能对lua不够熟悉导致的）。coroutine加上消息机制，其实确实是较为复杂的，比较难想。

        在地铁上刚有一点思路的时候，突然又想起另一个问题——coroutine真的是有必要的吗？

        正巧我们老大是一个经验极其老道的BigWorld脚本开发者，对Python开发复杂逻辑系统有自己特有的一套方法，他对coroutine比较不以为然。主要原因是异步逻辑开发中的很多坑，他都踩过，而且也找到了比较合适的方式避免。他认为coroutine一定会带来很多问题。这方面我没什么经验，但是我也认为一定会带来新的问题，比如一个函数，前半部分和后半部分的环境不一致……这是极其讨厌的。

        上网搜了很多协程相关的文章，读罢确实发现，协程确实是解决了很多服务开发时的callback hell等等问题……但是除了让代码清晰易读、减少琐碎的函数之外，并没有本质上的作用。

        

        接下来发散思维，考虑是否取消对协程的支持……第一个理由，加入协程，服务器框架的消息派发会复杂很多，我认为对效率肯定是有影响的。要知道，python相比lua，在简单逻辑上可能慢了一倍，greenlet作为一个第三方库也比lua原生的coroutine要重量一些，嵌入时也确实有很多麻烦。简单来说，我认为太难了，就算实现了，效率也可能不高，有点打退堂鼓。

        上面的理由可能站不住脚，但是第二点理由可能是关键性的——Meme框架最终要实现同步读、异步写，就是一个entity访问另一个entity的数据，并不需要call过去（发消息然后异步返回消息），只需要从内存中直接读就好了。因为Meme与skynet具有本质的不同。Meme没有沙盒，几乎所有entity是处于同一个Python环境中的，所以让同步读成为了可能。

        当然，读取一定会遇到data race，由于多线程而导致读取错误。这是Meme框架要解决的重点问题。

        同步读一旦实现，意味着什么呢？意味entity之间的消息传递次数，可能会降低非常多，几乎所有的“读”都不需要发消息了。这会减少异步操作，也减少了对greenlet的依赖。