共 26 篇相关文章
最近我们在开发引擎时遇到一个和操作系统有关的问题，想了个巧妙地方法解决。我感觉挺有意思，值得记录一下。 在 ios 上，如果你的程序没能及时处理系统发过来的消息（比如触摸消息等），系统有机会判定你的程序出了问题，可能主动把进程杀掉。 完全自己编写的应用程序，固然可以把处理消息循环放在最高优先级。即使有大量耗时操作，也可以通过合理的安排代码，不让消息处理延后。但作为引擎，很难阻止使用者阻塞住主线程做一些耗时的操作。所以，通常我们会把窗口消息循环和业务逻辑分离，放到两个不同的线程中。这样，消息处理线程总能及时的处理系统消息。
很多使用 Unity3D 开发的项目，都不太喜欢 C# 这门开发语言，对于游戏开发很多人还是更喜欢 Lua 一些。而 Lua 作为一门嵌入式语言，嵌入别的宿主中正是它说擅长的事。这些年，我见过许多人都做过 U3D 的 Lua 嵌入方案。比如我公司的阿楠同学用纯 C# 实现了一个 Lua 5.2 （用于在 U3D web 控件中嵌入 Lua 语言的 UniLua ）；还有 ulua slua wlua plua xlua ... 数不胜数。我猜测，a-z 这 26 个字母早就用完了。 上面提到的项目的作者不少是我很熟悉的朋友，我们公司现在的 U3D 游戏也由同事自己实现了一套差不多的东西。所以我曾了解过这些方案。但我一直觉得这些方案要么做的过于繁琐，要么有些细节上不太完备，总是手痒想按自己的想法搞搞看。
今天有同学跟我讨论了一下最近发现的一个 bug ，我觉得挺有意思的。 需求是这样的： 我们的系统中，有一些数据是从外存（数据库）加载进来的，由于性能考虑，并不需要每次修改这些数据就写回外存。希望在数据变冷后，定期落地即可。 典型的场景是一个 cache 模块，cache 的是一些玩家的业务数据，可以通过 uuid 从数据库索引到。一旦业务需要访问玩家数据，cache 模块会从数据库加载对应数据，然后把数据表交出去。当业务再次需要这些数据的时候，cache 模块一旦发现数据存在于 cache 中，就直接交给玩家。 cache 模块还希望在数据很久没有被业务访问时，将这些数据写回数据库。 我们的系统是基于 lua 构建的，数据 cache 模块和修改这些数据的逻辑在同一个 vm 里。难点在于，修改数据的业务逻辑是可以长期持有数据的，cache 模块需要正确感知这点。
Lua 作为一门嵌入式语言，提供了完备的 C API 供 Lua 代码和宿主程序交互，当然，宿主语言最好是 C 或 C++ 。如果是其它语言，比如最近两年流行的在 mono 环境嵌入 Lua 另当别论。 正确将 Lua 嵌入是不太容易做对的事情，很多刚接触 Lua 的人都容易犯错误。好在做这种语言桥接工作都是项目开始阶段的设计者做的，不必人人学会，所以只要有熟悉 Lua 的人来搞，犯错误的危害不会太大。而且即使做的有问题，日后修改也比较容易。这篇 blog 主要就是谈谈，最容易做错的位置，和一些正确（但看起来麻烦）的实现方法。
通常一个网站数据库挂掉后，后果将是非常严重的。基本上整个网站基本不可用了。对于一些网站来说，当数据库挂掉后，如果能提供基本的浏览服务，也是不错的。本文将尝试使用varnish + nginx + lua 搭建网站降级系统来实现整个目标。
昨天我们发现每日构建的服务器突然在一个晚上内存暴增了 8 G ，显然是发生了内存泄露。之前，我们在 skynet 里留下了许多调试协议，使我们很快的确定了发生泄露的服务：在一张地图的 lua State 中。可以确定是地图的 lua 实现中，有些 lua 对象在不断的生成。生成速度不快，但确实没有人解开引用，导致内存持续增长。
基本类型如何使用元表 在lua里只能为表设置元表,而在c程序里面可以为基本类型进行元表操作,但上篇博文提到了普通类型的很多操作是不会走到元表,下面的例子针对数字类型,添加多种事件,只有部分事件会生效.下面的例子在c代码里对数字类型添加元表对__add,__len都设置事件.
表是如何调度到元表的呢,上篇博文的例子我们看到当键值未能被查找到之后会调用__index事件对应的函数.现在举一个”__add”事件来遍历重要环节的源码..... arith_op是个宏,会针对操作数进行类型判断,如果是数字类型就会立即进行相加,这就是为什么基本类型即便设置了加减等事件函数后还是没有效果,例如你为数字的加法设置了__add事件后数字相加不会掉用这个元表方法,后面会举一个例子.
lua metatable(以下简称元表)类似c++的operator overloads,可以对复合结构进行操作,在lua里最常见的就是对表的操作.举例来说，当两个表作加法操作的时候,Lua会检查表的元表中是否有”__add”事件是否对应一个函数(metamethod)。如果存在Lua会调用这个函数来执行一次表的加法操作. __index和__newindex是表常常要添加的事件,用于处理键值在表无法被查找到之后的处理.
火云邪神语录：天下武功，无坚不破，唯快不破！Nginx的看家本领就是速度，Lua的拿手好戏亦是速度，这两者的结合在速度上无疑有基因上的优势。 最先将Nginx，Lua组合到一起的是OpenResty，它有一个ngx_lua模块，将Lua嵌入到了Nginx里面；随后Tengine也包含了ngx_lua模块。至于二者的区别：OpenResty是Nginx的Bundle；而Tengine则是Nginx的Fork。值得一提的是，OpenResty和Tengine均是国人自己创建的项目，前者主要由春哥和晓哲开发，后者主要由淘宝打理。
当我们在修改数据结构中某个副本时，为了修改过程的原子性，我们需要复制一个副本出来，修改，然后利用 CAS 交换到主干上。这个过程中，其它读线程，可能引用老的版本，读完后就需要销毁掉过期的版本。在有 GC 机制的语言中这非常简单。但是在 C/C++ 这种手动管理内存的条件下，几乎变得不可能。对，我们可以用引用计数来管理。但难点在于引用记数本身需要放在对象上，那么改写引用值却需要获得对象本身先，这个变成了绕不过去的死结。在并发条件下，如果你不使用锁，那么获得对象指针后，到操作引用记数之间，无法确保对象不在那一刻被其它线程减少引用而销毁掉。
在做策划表格解析的时候，我们希望可以在表格里直接填写一些脚本代码。我们的脚本语言使用的 Lua ，所以，直接填写 Lua 代码最为简单。但是，策划同学强烈需要在脚本中直接使用中文。而 Lua 原生并不支持使用中文作为变量名。一开始我们使用了一些变通的方案：比如建立一个字典，把中文词通过程序替换成相应的拼音。倒也能工作。 昨天在午饭途中的电梯里，我想到了另一个方案，用了一个下午实现出来验证可用。 修改 Lua 的语法解析代码，让其支持汉字并非难事。但我不太想通过给 Lua 打补丁，修改 Lua 语言的方式来做这件事情。即，我不想因为这个项目为 Lua 创造一门方言。但是，我们却可以把策划表格中填写的代码当成一种 DSL ，正如之前我实现的公式解析 那样。把这部分用 Lua 的方言来实现，把修改的影响减少到最小，而不蔓延到整个系统的实现语言中去，或许是个更好的方法。
如果你在同一个进程里有多个 lua state , 它们需要共享大量的只读数据, 那么可能就不希望在每个 state 启动的时候都加载和解析一遍这些数据. 所以我们需要一个共享只读数据的方法。 前段时间，我实现了一个 共享内存服务 ，这个可以保证共享内存的安全读写。不过，如果数据是只读的，那么就不需要这么复杂了。 我们只需要把数据加载到一个 lua state 中，其它的同一进程内的 state 通过 C 接口去读数据就可以了。 今天，我做了简单的实现，放在了 github 上。目前可以支持 nil number boolean function table 的数据交换。 function 交换有一些限制，不可以绑定 upvalue 。是用 string.dump 和 load 实现的。 table 类型返回的其实是一组 key ，需要继续用 get 来读取数据。
Lua 只支持一种 number ，默认是 double 类型。虽然你可以通过修改 luaconf.h 里的定义，把 lua number 改成 int64 。但是为了 int64 类型而放弃浮点数，恐怕不是大多数人想要的。 int64 通常用在 uuid 上，也就是说不需要对其数学运算，只需要可以比较就好了。我以前最喜欢的做法是用 8 bytes 长的 string 来表示一个 int64 。这样，即可以做唯一的 key 用，又不用做复杂的扩展。 在 pbc 的 lua binding 库 中，对 fixed64 类型，我就是这样处理的。今天遇到新的需求，有同学希望可以在项目中直接处理 64bit 的 timestamp 。
几个月以前，在我在 blog 上曾谈及 Lua 5.2 的改进。它可以用来实现抢占式多线程 。 周末休息，我把这桩事挖出来娱乐一下，花了一整个晚上做了实现。把 lua 的每个线程锁定在独立的 lua state 中，强迫线程之间通过消息管道的方式通讯。经过测试，Lua 5.2 每个独立的 state 占用的内存很小。通过自定义 alloc 函数可以测算出，一个干净的 32bit state ，不含任何库函数时，占用内存量在 2K 以下(1726 bytes)。如果加载基本库，也仅仅占用不到 4K (3265 bytes)。若把所有 lua 官方标准库加载进来，才会上升到 10K 以上(12456 bytes)。 对于 luajit 2 ，这个基础开销会大一些，最小开销也在 10K 左右 (8058 bytes) 。加上 ffi 达到 30k (31605 bytes)。不过 ffi 可
今天花了将近 3 个小时帮同事看一个崩在 lua VM 中的 bug 结果打乱了进度，没有在年前把预想的东西做完。其实说起来这不是个大问题，以前也碰到过。我检讨自己没有在看到出错时的调用栈时去看一眼 lua 相关的代码。如果是那样，因为以前遇到过同样的问题，所以就可以条件反射出问题原因，而不用荒废宝贵了数小时时间了。 唉，这下整合的进度没接上，过年不能自己一个人接着做下面的活了。 下面记录一下这个 bug ，提醒自己第三次...
虽然 luajit 和 lua 5.2 还有点小矛盾，luajit 没有完全支持 lua 5.2 的迹象。不过，这些对 Lua 社区都是好消息啦。可能对于 lua 用户会有点小纠结，到底是追随官方的 5.2 版呢，还是去用性能更好的 luajit2 。我比较在意性能，暂时先投靠 luajit 了。反正和 5.2 区别也不大。更重要的是，luajit2 提供的 ffi 库相当之好用，极大的减少了我们写 C 库的 lua binding 的负担。从某种角度可以看到另一个问题，为基础设施模块设计出良好的 C 接口(而不是 C++ 的)是多么的重要。
前几天分析了 lua gc 的实现细节。 阅读 lua 的代码是段很有趣的经历。但如果是重头读 lua 的源码，建议从简单的部分读起。gc 恰巧是最难的一段。LuaJIT 的作者 Mike 在这方面很有发言权，他在回答 Which OSS codebases out there are so well designed that you...
GC 中最繁杂的 mark 部分已经谈完了。剩下的东西很简单。今天一次可以写完。 sweep 分两个步骤，一个是清理字符串，另一个是清理其它对象。
今天来说说 write barrier 。 在 GC 的扫描过程中，由于分步执行，难免会出现少描了一半时，那些已经被置黑的对象又被修改，需要重新标记的情况。这就需要在改写对象时，建立 write barrier 。在扫描过程中触发 write barrier 的操作影响的对象被正确染色，或是把需要再染色的对象记录下来，留到 mark 的最后阶段 atomic 完成。
