我正在制作的游戏 demo 中，所有对象逻辑上都存在于二维空间，但在 Ant Engine 中通过 3d 渲染方式绘制出来。
我希望有一组简便的 API 方便我控制这些对象的渲染，只是控制它们的位置以及在 Y 轴上的旋转量。Ant Engine 是用场景组件来控制 entity 渲染时的空间状态，但场景节点使用的是 3d 空间的 SRT 即缩放、旋转、位移。而我只需要控制其中的两个坐标轴上的空间位置以及一个旋转轴上的旋转量，直接修改 SRT 太不方便了。而且，使用引擎时，还需要每帧标记被修改过的场景组件对应的 entity ，这也很麻烦。
在 ECS 结构下，最简单的方式是为这些 entity 创建一个额外的组件，里面有 x y r 三个值。通过一个 system 把它们转换到场景节点在 3d 空间下的 SRT 组件中。但如果每帧都全部转换一次显得多余，毕竟大部分 entity 不是每帧都会发生变化的。
我用了一个简单的 Lua 技巧来方便开发，下面便是代码：
Lua 的数据类型非常有限，用 C 编写的 Lua 模块也没有统一的生态。在不同模块间传递内存块就是件很头疼的事情。
简单通用的方法就是用 Lua 内建的 string 类型表示内存块。比如 Lua 原生的 IO 库就是这么干的。读取文件接口返回的就是字符串。但这样做有额外的内存复制开销。如果你用 Lua 编写一个处理文件的程序，即使你的处理函数也是 C 编写的模块，也会复制大量的临时字符串。
我们的游戏引擎是基于 Lua 开发的，在文件 IO 上就封装了自己的库，就是为了减少这个不必要的字符串复制开销。比如读一个贴图、模型、材质等文件，最后把它们生成成渲染层用的 handle ，数据并不需要停留在 Lua 虚拟机里。但是，文件 IO 和资源组装（比如贴图构造）的部分是两个不同的 C 模块，这就需要有效的内存交换协议。
上周看到了 Redis 作者的新玩具语言 Aocla ，感觉很有启发。它是 FORTH 和 Lisp 的杂合体，又增加了一些内嵌局部变量的支持。非常像我前两年给我们数学库做的一个小东西。最初的想法是为数学库设计一个 DSL 潜入 Lua ，在做复杂的数学计算过程时，可以把计算过程停留在 C Side ，减少 Lua 和 C 之间的边界成本。最初的版本是我模仿 FORTH 设计的基于栈的小语言。希望牺牲一些表达能力，换取一点性能。但实用起来过于别扭，后来又增加了一些特性却没有本质改进。最后终于决定把这个 DSL 彻底从数学库中剥离了 。
绝大部分的基础数据结构都是定长的，很容易针对优化它们的内存管理。但字符串是一个例外。
内存管理和其它资源管理有明显的不同。管理内存有点像切蛋糕，从整块蛋糕上切下需要的那块，但归还的时候却因为支离破碎难以合并起来满足后续用途。举个极端的例子：如果内存堆有 2G 大小，如果碰巧在正中间分配了几个字节而从未释放，这个堆就被永久的分成了两个不足 1G 的分片。之后再无可能从这个 2G 大小的堆中分配出 1G 的内存块。
改进内存分配算法或许可以减轻内存碎片的危害，但即使是在此方面做了相当多努力的 jemalloc ，其表现也大大低于一般用户的预期。以我的经验，一个 16G 的内存堆，对于长期运行，需要大量反复分配释放内存的程序，通常能做到 10G 左右的峰值有效内存占用就不错了。这里说的有效内存使用，指你调用 malloc 传入的字节数之和。根据应用程序使用内存的方式不同，这个数字会有很大的不同。
60% 的内存使用率其实已经很好了，但还是会有很多人问，我的内存都去哪了？
最近半个月，因为广州防疫政策，我一直居家办公。找了点时间，给 skynet 做了一年一度的 release 。
这次的 1.6.0 版，相比去年的 1.5.0 版，没有太大的变化。主要是平时积累的一些 bugfix 。它所依赖的第三方库，例如 Lua , jemalloc 我都更新到了最新的版本。
值得一提的是，mongo 的 driver 也更新了。因为 mongo 在最新的版本中已经淘汰了旧的 wire protocol ，如果再不更新，就无法连接新版 mongo server 了。具体讨论可以参看 PR #1649 。因为 mongo 自己的设计原因，我们无法给出一个同时兼容新老版本协议的方案。从这点来看，我个人认为 redis 的底层协议设计就稳定的多。 这么多年更迭基本不需要修改。
ltask 是一个功能类似 skynet 的库。我主要将它用于客户端环境。由于比 skynet 后设计，所以我在它上面实验了许多新想法。
最近碰到一个需求：我们的游戏引擎中嵌入的第三方 C/C++ 模块以 callback 形式提供了若干接口。在把这些模块嵌入 ltask 的服务中运行时，这些 callback 函数是难以使用全部 ltask 的特性。比如，我们的 IO 操作全部在一个独立服务中，引擎读取文件时，很可能是通过网络异步远程加载数据的。这些第三方模块通常没有考虑异步 IO 操作，都是以同步 IO 方式给出一个读文件的 callback 函数让使用者填写。
那么，怎样才能在这个 C callback 中挂起当前任务，等待 IO 的异步完成呢？
我们引擎中使用的数学库已经修修补补很久了。期间积累了很多想法。最近在对引擎做性能优化，把一些找到的热点系统用 C/C++ 改写，顺便就重构了一下数学库，让它更好的兼顾 Lua API 和 C API 。
上一次对数学库的改进是三年前的事情了。这三年的使用，我们发现，基于一个栈的 DSL 虽然可以减轻 Lua 和 C 之间的通讯成本，但是使用起来并不方便。大部分时候，我们还是倾向更传统的接口：一次数学运算调用一次函数。而高复杂度的数学运算完全可以放在独立的 C 模块中完成。结合 ECS 系统，我们可以在 C side 集中批量处理相同但数量巨大的数学运算。
我们在很早以前就放弃了原来设计的 DSL ，只使用数学库的部分功能。趁这次重构，我打算把这些已经废弃的部分彻底删掉，并重新设计底层的数据结构，让它能更好的适应其核心特性。
VLA （可变长度数组） 是 C 语言在 C99 之后加入的一个很方便的语言特性，但是 MSVC 已经明确不支持 VLA 了。而且 Linux 的内核代码中曾经使用过 VLA ，而现在已经移除了 VLA 。看起来，VLA 带来的安全问题比它的便利性要多。
但是，日常用 C 语言做开发时，经常还是需要变长数组的。既然直接用 C 语言的 VLA 有诸多问题，那么还是需要额外实现一个比较好。C 没有 C++ 那样的模板支持，一般的通用 VLA 实现很难做到类型安全。即使用 C++ ，STL 中的 vector ，这个最常用的 VLA 实现，也不总是切合应用场景的。比如，std::vector 它的数据一般还是分配在堆上，而不是栈上。相比原生创建在栈上的数组，它可能性能有影响且有可能制造更多的堆内存碎片。
我认为一个通用的 VLA 库，应该做到：
今天修了个 skynet 中的 bug ：在 Lua 中重新设置 callback 函数会失效。
skynet 已经有 10 年的历史了，十年前，某些 lua 的惯用法我还不太熟悉。比如，如果一个 C 框架的接口设置了一个回调函数，如何将其 binding 到 Lua 函数上，我当初没有想到好的方法。
最为传统的方法是把 Lua callback function 放到 Lua 的注册表中。当 C 框架的 callback 发生时，在 C 版本的 callback 函数中去查找 Lua 注册表中的 callback function ，然后用 pcall 执行它。
几乎大部分 C 模块的 lua binding 都用这个方案来封装 callback 函数。但它有一个最大的问题：调用 lua callback function 时，Lua 的状态机 L 如何传递。
年前最后两天，陆续给我们组的同事批了假，都回家过年了。我留守在公司做点项目无关的东西。
最近在 skynet 的讨论版有人讨论配置表的更新问题。这几年，不管在公司内，还是从外部听见，总有人在讨论这个问题。我重新理了一下需求：
2021 年 12 月 21 日，Lua 发布了 Lua 5.4.4 rc2 。
Lua 5.4.4 这个版本相当难产。之前几个小版本从 rc1 到正式发布最多只有十几天，而这次这个版本已经过去一个月，看起来还不能正式发布。
因为，就在 rc2 发布几个小时后，在邮件列表的讨论中，有人就发现了一个 bug 。有趣的是，这个 bug 并不是 Lua 5.4.4 引入的，而已经存在了 10 年以上。
2021 年 12 月 21 日，Lua 发布了 Lua 5.4.4 rc2 。
Lua 5.4.4 这个版本相当难产。之前几个小版本从 rc1 到正式发布最多只有十几天，而这次这个版本已经过去一个月，看起来还不能正式发布。
因为，就在 rc2 发布几个小时后，在邮件列表的讨论中，有人就发现了一个 bug 。有趣的是，这个 bug 并不是 Lua 5.4.4 引入的，而已经存在了 10 年以上。
这两天写代码时用到之前写的一个对 Lua 配置表的 cache 模块 。感觉用起来还是不够简洁方便。我今天动手重新设计了一下。
需求是这样的：
项目有非常多的配置信息保存在 Lua 的 （树状层级的）table 中，大部分逻辑代码直接用 Lua 的语法便可直接访问。但是，有少量有性能要求的业务是在 C 中实现的，C function 中也需要读取这些存放在 Lua 中的配置数据。
配置项随着项目开发，变更非常频繁。如果我设计一个小语言，定义出配置表，用代码生成的方式把表项翻译成对应的 C/C++ 结构，再在 C side 根据 Lua 中的数据重建一组 C 数据也未尝不可。这就是 google protobuf 官方采用的方式（用代码生成的方式，根据数据的 schema 构建出 C++ 类，让 C++ 可以方便访问这些数据）。
但我不想搞得这么复杂（浪费？）。大部分业务循环次数很多，而需要读取的配置表象却比较单一（反复取相同的条目）。所以，虽然第一次通过字符串 key 逐级解析 Lua 配置表或许较为低效；但只要在 C side 用一个 cache 模块缓存下高频访问的配置项应该就能解决性能瓶颈。
最近在尝试做一个类似异星工厂的游戏原型。由于最终希望在内存有限的手机上运行，所以不得不考虑内存如何有效利用的问题。
这是因为，我在玩异星工厂（加上一些 mod ）时，发现 PC 内存能占到 10G 以上，且这些内存大部分都不是图像资源，是实打实的逻辑数据。我稍微估算了一下，在一些内容丰富的 mod 中，游戏内的对象能够达到数十万，甚至上百万之多。用传统方法使用的内存势必以 G 计算。
如果希望同样的逻辑跑在手机上，我希望把逻辑数据控制在 500M 之下。除了从游戏玩法做做一些限制外，还需要对逻辑占用的内存精打细算。
最近有点关于 Lua 不成熟的想法。
Lua 目前函数原型的常量表只支持了布尔、数字和字符串类型的常量。而 table function 这些是不会存在于常量表中的。
我想，如果常量如果不限于前三种类型，可能会更好一些。比如，一个惯用法是在代码前面写上
local pairs = pairs
这个惯用法是基于 local 变量比全局变量少一次 hash 表查询，性能可能会高一点。 但实际上，往往差距并不大。而这种写法还会给其它应用 pairs 的函数增加额外的 upvalue ，很有可能得不偿失。
最近有点关于 Lua 不成熟的想法。
Lua 目前函数原型的常量表只支持了布尔、数字和字符串类型的常量。而 table function 这些是不会存在于常量表中的。
我想，如果常量如果不限于前三种类型，可能会更好一些。比如，一个惯用法是在代码前面写上
local pairs = pairs
这个惯用法是基于 local 变量比全局变量少一次 hash 表查询，性能可能会高一点。 但实际上，往往差距并不大。而这种写法还会给其它应用 pairs 的函数增加额外的 upvalue ，很有可能得不偿失。
这个项目复用了我之前的一个类似项目的名字 。目的是一样的，但是我做了全新的设计。所以我干脆将以前的仓库移除，以同样的名字创建了新的仓库。
和之前的版本设计不同。在消息通讯机制上，这个更接近 skynet 的模型，但它是一个库而不是一个框架。调度模块是按前段时间的想法实现的，不过只做了一个初步的模型，细节上还有一些工作待完善。
这几天在给 RmlUi 这个库写 Lua binding 。
这个库原本有一个官方的 lua binding ，但是新特性 Data Model 却没有实现。作者坦承自己对 Lua 不是特别熟悉，这个新特性也在开发中，暂时没想好该怎么做，所以只完成了 C++ 接口，Lua 接口留待这方面跟懂的人来做。
我觉得这个新特性有点意思，打算帮助这个项目实现 Lua 接口。在实现的过程中，发现原版的 Lua binding 做的过于复杂，且那些复杂度完全没有必要。所以打算自己全部重新实现一套。
最近给 bgfx 的 lua binding 做了一点改进，因为修改了原有的 api 语义，所以需要做一点记录。
对于 3d 库来说，API 涉及大量的内存块的操作。创建 Buffer ，贴图，shader ，都需要输入一个数据块。大多数数据块是只读的，少部分是需要回写的。对于只读数据块，封装层可以用 lua string 替代，可写的用 userdata 。
bgfx 自己抽象了一个叫做 Memory 的结构，用来统一描述这类内存块对象。按 bgfx 的定义，Memory 的构造由用户决定，而释放通常由 bgfx 管理，而非调用者。
即，用户负责构造出 Memory 对象，将数据拷贝进去，然后再传递给 bgfx 的 api 后就可以撒手不管了。但是，如果你构造出 Memory 对象不传递给 bgfx 则会造成内存泄漏（因为没有任何直接释放它的方法）；也不可以将一个 Memory 对象使用多次（传递给 bgfx 多次），因为一旦传给 bgfx ，就失去了对象的控制权。
最近一段时间，lua 的邮件列表中有好几个主题讨论 hash 表的设计。我读下来受益匪浅。比如 前两周的这个主题 中，有同学主张去掉 lua hash table 中的链表指针，而改成固定步长的冲突链表。具体这里就不展开了，有兴趣的同学可以自己看。
这两天的讨论是围绕 lua 的 hash 函数的，暂时还没有固定链接，我把我的理解和思考记录下来，不一定正确，如有行家发现错误，请不吝赐教。
unsigned int
luaS_hash (const char *str, size_t l, unsigned int seed, size_t step) {
unsigned int h = seed ^ cast_uint(l);
for (; l >= step; l -= step)
h ^= ((h<<5) + (h>>2) + cast_byte(str[l - 1]));
return h;
}
来看这样一个 hash 函数：
最近我们在开发引擎时遇到一个和操作系统有关的问题，想了个巧妙地方法解决。我感觉挺有意思，值得记录一下。
在 ios 上，如果你的程序没能及时处理系统发过来的消息（比如触摸消息等），系统有机会判定你的程序出了问题，可能主动把进程杀掉。
完全自己编写的应用程序，固然可以把处理消息循环放在最高优先级。即使有大量耗时操作，也可以通过合理的安排代码，不让消息处理延后。但作为引擎，很难阻止使用者阻塞住主线程做一些耗时的操作。所以，通常我们会把窗口消息循环和业务逻辑分离，放到两个不同的线程中。这样，消息处理线程总能及时的处理系统消息。
在 windows 上，允许程序在任何一个线程做窗口消息循环。但在 ios （以及 Mac）上似乎不行。窗口消息循环必须在主线程中运行。
前两天写了 快速字符串对象比较 ，我把这个想法提交到 Lua 的邮件列表，建议 Lua 的未来版本去掉长短字符串，不做 string interning ，用这个方法解决字符串比较的性能问题。Lua 的主要维护者 Reberbo 表示了兴趣，同时也提出了几点问题。
其中一个问题是，Lua 未必运行在 64bit 平台上，所以并没有直接使用 64bit 整数类型。而如果使用 32bit id 就无法简单的通过自增来保证 id 永远唯一。
我就这个问题考虑了几天，提了好几个解决方案，其中一个方案我最为满意，在这里重新用中文记录一下。
这段时间在想办法解决多个 lua 虚拟机间共享对象的问题。这里的一个核心问题是，lua 的短字符串做了 interning ，虚拟机在比较两个字符串时只需要比较字符串对象指针即可。而多个 lua vm 如果想共享数据，必须解决这个问题。前段时间实现的 并发 Hash Map ，和 共享表 就是在这方面做的努力。
随着 lua 5.4 的临近，我最近尝试了在 lua 5.4 的 alpha 版上做类似的 patch 。但是 lua 5.4 对 gc 的修改极大，这让我尝试去找其它的办法来做这件事。
我觉得，如果允许 vm 在处理短字符串比较时，不严格遵守 interning 的约定，那么就不再需要对 gc 流程做改造了。这样，从外部共享来的字符串，只要做全量值比较，依然可以得到正确的结果。
这样的修改固然对 lua 的代码影响极小，但很可能会有很大的性能损失。毕竟，字符串比较从原来的 O(1) 一次指针比较，变成了复杂得多的 memcmp O(n) 。而这明显是 vm 的性能瓶颈所在。
Lua 中的短字符串做了 string interning 的处理，即在同一个虚拟机内，值相同的字符串只存在一份。这可以极大的提高用字符串做 key 的 hash 表的查询速度。因为字符串比较的时间复杂度从 O(n) 下降到 O(1) ，比较查询的 key 和 hash 表内的 key 是否一致，只需要对比一下对象的指针是否相同即可。
我在解决多 Lua 虚拟机共享字符串对象这个问题时，合并了不同的 Lua 虚拟机中的短字符串表。让同一进程所有虚拟机共享一个短字符串表（ SSM ）。
我最初在实现 SSM 的时候，考虑到多虚拟机 GC 的复杂性，采用了只增不减的方案。即让部分短字符串进入 SSM ，设置一个上限，避免 SSM 无线膨胀。但 Lua 并没有把经过 interning 处理的字符串作为独立类型，目前只用字符串长度作为区分，也就是无法和不 interning 的短字符串共存。所以，那些已存在本地虚拟机短字符串表中的字符串，就不从 SSM 中获取对象。
修改过 Lua 的 string interning 算法是这样的：
查看字符串是否存在于本地字符串表 (LSM) 如果存在，就立刻返回。这一步和原版 Lua 一致。
查看字符串是否存在于 SSM ，如果存在，就返回。
检查是否 SSM 上限已到，如果不能再增加新字符串，把字符串添加到 LSM ，返回。
将字符串添加到 SSM ，返回。
我为我们正在研发的 3d 引擎设计了一个非常规的数学运算模块。
它和很多为 Lua 封装的数学运算模块不同，并没有用 userdata 或 table 来实现矩阵向量对象，而是采用了 64bit 的整数 id 。其生命期管理是模拟了一个堆栈，我称之为数学栈，和程序运行时存放临时变量的堆栈以示区分。数学栈上存在过的矩阵向量对象的生命期都会维持一个固定周期，通常是一个渲染帧。每帧主动调用重置指令刷新。这个设计减少了在 lua 层面使用矩阵向量对象的心智负担。你不必担心运算产生的临时结果会增加过多 gc 的负担。构造新的矩阵向量对象的成本也非常的小。
在我们的服务器框架 skynet 中，往往会在同一进程启动非常多的 lua 虚拟机，而大多数几乎运行着相同的代码（为不同的用户服务）。
因为 Lua 的代码也是数据，和 Erlang 这种天生设计成多服务的语言不通，Lua 并没有为多虚拟机同时运行做内存上的优化。所以，我在 5 年前给 Lua 制作了一个 patch ，可以把不同虚拟机间的函数原型数据提取出来共享一份，节省了不少内存。
不过，这个方案只能功能函数原型中的字节码以及调试信息，无法共享函数原型用到的常量表。这是因为，字符串常量是一个对象，尤其是短字符串，Lua 在虚拟机内部做了 interning 已加快字符串比较速度，使得它们很难在虚拟机间共享。
如果你有关注 lua 在 github 上的仓库，就会发现，最近一段时间增加了一个新特性：to-be-closed 的 local 变量。
鉴于历史上 lua 每次的大版本开发过程中都会增加很多有趣的特性，却无法保持到版本正式发布。本文也只是介绍一下这个有趣的特性，并不保证它一定会被纳入语言标准。正式的发布版中即使有这个特性，语法上也可能有所不同。
我认为 Lua 加入这个特性的动机是它缺乏 RAII 机制。过去，我们必须用 pcall 来确保一段代码运行完毕，然后再清理相关的资源。这会导致代码实现繁琐，几乎无法正确实施。比如，如果你用 C 函数申请了一块资源，期望在使用完毕后可以清除干净，过去就只能依赖 __gc 方法。但 gc 的时机不可控，往往无法及时清理。如果你把释放过程放在运行过程的末尾，是很难确定整个运行过程中没有异常跳出的可能，那样就无法执行最后的释放流程。
上次在 blog 上写 Lua GC 是 2011 年，lua 5.2 尚未发布时候的事情了。我认为仔细研读优秀开源代码是非常值得做的事情，但把研读过程写出来却意义不大。代人咀嚼这事吃力不讨好，每个人的技术背景不同，写得过细浪费阅读时间，写的粗糙又会使读者不得要领。一行行读代码本就只是件辛苦活，任何人沉下心来都能做到，想通过别人代读而节省时间，多半是做不到的。所以我那本 Lua 源码欣赏 也就一直搁置了。
沉在代码的逐行细节中往往一叶障目，反不如高屋建瓴的理解一下作者的思想。今年的 lua workshop ，Lua 的主要维护者 Roberto Ierusalimschy 做了题为 Garbage collection in Lua 的演讲，很好的讲述了 Lua 历史各个版本的 gc 算法实现。我没有听这个演讲，但阅读 Slide 结合源代码基本可以搞明白。这篇 Blog 分享一下我的理解。注意：我添加了许多自己的理解，很可能和演讲原意有极大的偏差。所以本篇仅代表我的个人立场。
我打算就我们在开发客户端引擎框架时最近遇到的两个问题写两篇 Blog ，这里先谈第一个问题。
我们的框架技术选型是用 Lua 做开发。和很多 C++ 开发背景（现有大部分的游戏客户端引擎使用 C++ 开发）的人的认知不同，我们并不把 Lua 作为一个嵌入式脚本来看待，而是把它当成一种通用语言来设计整个引擎框架。
其实这更接近 HTML5 流行之后，用 javascript 设计游戏引擎框架：虽然 javascript 的虚拟机本身是用 C++ 开发的，但和游戏引擎相关的部分全部用 javascript 实现，直到涉及渲染的部分，又通过 WebGL 回到 C++ 编写的代码中。这里，我只是把 javascript 换成了 Lua 而已。
选择 Lua 有很大成分是因为我的个人偏好，另一部分原因是 Lua 有优秀的和 C/C++ 代码交互的能力。可以方便地把性能热点模块，在设计上做出良好的抽象后，用 C/C++ 编写高性能的模块，交给 Lua 调用。
但和 Javascript 不同，我们在做原生 App 时，和操作系统打交道的部分还是得用操作系统的语言，C/C++/Objective C/Java 等等。Lua 虚拟机还是要通过一个 C 模块实现嵌入到 App 中去，这个工作得我们自己来完成。
让 Lua VM 置入 App 和操作系统打交道的这部分代码显然是平台相关的，Lua 的 C API 固然简洁，但是还是很庞大的。如果每个平台都直接用 Lua C API 控制虚拟机，这些平台相关的代码还是略显繁杂。我认为，把平台相关代码约束到一个足够小的范围，还需要对 Lua C API 再做一次抽象。
我为 3d engine 项目设计的向量运算库 已经用了一段时间了。在使用过程中也一直在改进 。从一开始，我就考虑过，这个库的设计主要考量是减少 lua 和 C 交互间的开销，提高内聚性。而易用性方面，计划再上面再做封装。这段时间继续在想怎样从更自然的表达形式转换到这个库的逆波兰指令流上。
大致的方向有两个：
其一，实现一个小语言，用字符串输入表达式组。
其二，利用 Lua 已有的语法解析设施，把 lua 的一个函数翻译成对应的数学运算指令流。
两者都可以看成是一种 jit 的过程，在第一次运行的时候，做一些翻译工作，把要进行的数学运算打包成 C 代码可以处理的指令流，或翻译成现有数学库支持的指令流；或者，增加一个 lua 源码的预处理流程，在预处理阶段做好编译工作（aot）。
这个需求可以分解成三个问题：
首先，如何把更易用的的源码对接到 lua 原生代码。
其次，如何转换为正确的数学运算指令流。
最后，为以上过程选择 jit 或 aot 集成。
Lua 社区最近的一件大事是 Lua 5.4 的 work1 版本发布了。
这次的首发版本中引入了一个试验性的新特性，用来解决将 nil 放入数组的问题。因为是实验性特性，所以开发组决定默认关闭，必须在编译源代码的时候定义 LUA_NILINTABLE 这个宏才能开启。注意：默认是不开启的，后面的讨论都以这个为基础。
在邮件列表的讨论中，有不少人引入了不必要的激烈情绪，反对这种影响兼容性的改变。 Roberto 同学看起来是生气了，用全大写字母又重新强调了一次。当然虽然也有人不仔细阅读就评论，也比充斥在网络的大部分地方的喷子要强得多。
我觉得阅读整个讨论能加深对 Lua 语言的理解，非常有价值。这里做一点记录。毕竟，深入学习任何东西都回避不了了解其历史。每次 Lua 的版本升级的预发阶段，都会引入一些有趣的东西，大多数又会在正式版本发布前删掉。说明 Lua 的开发团队在语言设计上是及其谨慎的，我们要追寻这些历史痕迹，也只能从这些讨论中发掘了。
对于不太熟悉 Lua 的同学来说，我们先简单介绍一下这个特性的缘由。
前段为 3d engine 写的向量运算库小伙伴在用，提了很多意见，所以这段时间一直在改进。
一开始觉得逆波兰表示法的运算表达式不太习惯，觉得需要绕个弯想问题，希望做一个表达式编译的东西，但是用了几天后，又觉得其实不是什么大问题，习惯了就好了。
但心智负担比较大的地方是那个 id 的正负号约定，也就是生命期管理。我想了一下，人为的去管理生命期，有些对象是要长期持有的，有些对象只在当前渲染帧使用，在使用的时候严格区分它们不太现实。
一开始的版本，我需要使用者在计算表达式中用一个 mark 'M' 指令，把一个临时对象转换成一个持久对象，这极大的增加了使用者的负担。尤其是更新一个对象的时候，需要先解除老对象的持久状态，再 mark 新生成的对象。使用的时候需要一直考虑这个对象是不是要更新，用起来太困难了。虽然有强检查，不会把程序弄混乱，但是稍不注意就会报告运行时错（对象 id 失效）。
今天，我做了极大的调整，去掉了之前 mark 语义，增加了引用语义。
lua 从 5.2 开始，简化了 5.1 中的模块管理方式，然后一直保持到现在这个样子。
模块用 require 加载，同名模块在一个 vm 中只加载一次，第 2 次开始会返回上次加载的结果。加载模块时会利用 package.path 或 package.cpath 中定义的字符串模板，把模块名转换为文件名，依次尝试打开文件。
我在新项目中，由于整合了不少模块，感觉现有的这套机制有点点不够用。所以我做了一点点小改动，支持了类似 python 的模块管理那样的相对机制。当在一个模块中 require 另一个模块时，会先尝试加载相对路径上的模块，再尝试绝对路径。这样可以方便我们集成独立开始的模块，并放在独立的名字空间中。也方便给模块内置测试子模块。
例如，我独立开发了一个叫 foobar 的模块，它自己有一个子模块叫 foobar.baz ，在集成到系统中时，我希望把它们一起放在 common 名字空间下。使用的时候可以用 require "common.foobar" 来引用。
如果直接用 lua 原生的模块管理机制，我需要修改 foobar 主模块的代码，把里面的 require "foobar.baz" 改成 require "common.foobar.baz" 。同理，如果我不满意 foobar 这个名字，想换名也很麻烦。
如果用纯 lua 来做向量/矩阵运算在性能要求很高的场合通常是不可接受的。但即使封装成 C 库，传统的方法也比较重。若把每个 vector 都封装为 userdata ，有效载荷很低。一个 float vector 4 ，本身只有 16 字节，而 userdata 本身需要额外 40 字节来维护；4 阶 float 矩阵也不过 64 字节。更不用说在向量运算过程中大量产生的临时对象所带来的 gc 负担了。
采用 lightuserdata 在内存额外开销方面会好一点点，但是生命期管理又会成为及其烦心的事。不像 C 中可以使用栈作临时储存，C++ 中有 RAII 。且使用 api 的时候也会变得比较繁琐。
我一度觉得在 lua 层面提供向量运算的基础模块是不是粒度太细了。曾经也想过许多方法来改善这方面。这两天实践了一下想了有一段时间的方案，感觉能初步满意。
首先，我们在 2011 年底开创的简悦被阿里巴巴文化娱乐集团全资收购了。原来简悦的全套班底转型为阿里大文娱游戏事业群。
当收购的事情尘埃落定，我发现可以从新的视角来看待未来，重新设计制作一款 3d 引擎这件事可以重新启动了。在简悦一直想做而做不了这件事，是因为没有余力，必须优先考虑产品盈利；而对于阿里来说，投入资源来做这样一件短期没有收益，但长远看来却很有意义的事是很自然的。
世面上已经有了很多优秀的 3d 游戏引擎，比如目前最为流行的 Unity 和口碑优异的 Unreal ，还有许多品质精良的开源引擎，再从头做一个又有什么意义？
我是这么看这个问题的。
Unity 和 Unreal 固然优秀，但是它们在设计之初并没有把移动设备作为核心平台来考虑。发展历史悠久，固然细节上的完善是后来者无法比拟的，但也存在很多历史包袱。尤其是移动平台上需要特别考虑内存紧致、节约能耗，更胜过运行的更快、效果更华丽。
另外，就国情而言，我们需要的移动游戏需要有更弹性的资源管理以及更新方案，这一直是 Unity 的弱项。Unity 作为一个闭源引擎，很难让使用者做出根本改进。
我们已经和 Unity 达成了合作，购买了全部源码。现在公司也成立了专门的团队自己维护 Unity 源码对其他产品团队做技术支持。在这种情况下，重新抄一个 Unity 没有意义：有什么需求，我们完全可以在 Unity 源码的基础上做开发。所以我要的是一个全新的东西。
最近在用 Lua 实现一个 ECS 框架，用到了一些有趣的 Lua 语法技巧。
在 ECS 框架中，Component 是没有方法只有数据的，方法全部写在 System 中。Entity 本身仅仅是 Component 的组合，通常用一个 id 表示。
但实际写代码的时候，使用面向对象的语法（用 Lua 的冒号 这个语法糖）却是比较自然的写法。比如我们在操作一个 Component 数据的时候，用 component:foobar() 比用 foobar(component) 要舒服一些。好在 Lua 是一门非常动态的语言，我们有一些语法技巧在保持上面 ECS 原则的前提下，兼顾编码的书写体验。
最近在 windows 做开发比较多，lua 原生库使用的都是 C 标准库中的函数，比如文件操作就是用的 fopen 打开文件。这对 unicode 支持的很糟糕。我希望所有和文件名打交道的地方都使用 utf-8 编码，所以今天花了一点时间实现了这么一个库。
我把 lua 原生库中和文件名有关的 api 都重新实现了一遍，包括了：loadfile , dofile , os.rename , os.remove , os.execute, os.getenv , 以及 io.open 。除了 require 都可以在接口上使用 utf-8 字符串了。这里 require 是偷懒没支持 :)
前两年有同学给我推荐了 BGFX 这个库，第一眼被它吸引是它的口号："Bring Your Own Engine/Framework" style rendering library 。这动不动就说自己是 3d engine 的时代，好好做好一个渲染库，仅仅做好渲染库，是多难得的一件事情。
今年国庆节的时候，偶然间我又翻到这个仓库，居然作者一直在更新。坚持了五年，一直在维护这么个小玩意，让我对这个项目多了点信心。节后我饶有兴趣的研究了一下它的代码。
现在我觉得，这个库的设计思想非常对我的胃口，核心部分几乎没有多余的东西：数据计算、平台 API 支持、数据持久化格式支持、等等都没有放在核心部分。它仅仅只做了一件事：把不同平台的图形 API ：Direct X 、OpenGL 等等整合为一套统一的接口，方便在此基础上开发跨平台的 3d 图形程序。不同平台的 3d api 的差异，正是 3d 游戏开发中最脏最累的活了。
昨天我们一个项目发现了一处死循环的 bug ，经过一整晚的排查，终于确认是 lua 5.3.4 的问题。
起因是最近项目中接入了我前段时间写的一个库，用来给客户端加载大量配置表格数据 。它的原理是将数据表先转换为 C 结构，放在一块连续内存里。在运行时，可以根据需要提取出其中用到的部分加载都虚拟机中。这样做可以极大的提高加载速度。项目在用的时候还做了一点点小修改，把数据表都设置成 weaktable ，可以让暂时不用的数据项可以回收掉。
正式后面这个小修改触发了 bug 。
最近同事碰到的一个需求：需要频繁把一组数据在 skynet 中跨网络传递，而这组数据实际变化并不频繁，所以做了大量重复的序列化和传输工作。
更具体一点说，他在 skynet 中设计了一个网关节点，这个网关服务可以负责把一条消息广播给一组客户端，每个客户端由内部的一个 uuid 串识别，而每条消息都附带有客户端 uuid 列表。而实际上这些 uuid 列表组有大量的重复。每条广播消息都重复打包了列表组，且列表组有大量重复信息。
一开始我想的方法是专门针对这个需求设计一组协议，给发送过的数据组编上 id ，然后在发送方和接收方都根据 id 压缩通讯数据。即，第一次发送时，发送全量信息，之后再根据数据变化发送差异；如果完全没有变化，则只需要发送 id 。
之后我想，能不能设计一种较为通用的差异同步方法，可以在跨节点传递数据组的时候，避免将相同的数据重复传输，而采用差异同步的方法同步对象。
又一篇谈 Lua debugger 的 blog 了。但这次，并不是我的个人作品 :) 。
去年底我写了 如何优雅的实现一个 lua 调试器 。正如我的 blog 中所写：“不过期待它短期内发展成为一个图形式的漂亮交互调试器可能有点不现实，除非做前端的朋友有兴趣来完善它。”
ok 。这次，真的有人来完善它了。
我公司的前端大神突然对实现一个 lua debugger 产生了兴趣。他觉得既然 chrome 可以用来调试 javascript ，那么魔改一下后，调试 lua 也完全没有问题。利用几个月的业余时间，他完成了这么个东西：
ps. 不愧是做前端出身啊，开源项目的主页比 skynet 好看多了。
今天试了一下一个想法：绕过 lua 提供的 C API 直接去访问 lua 的表结构，提供在性能及其重要的环境高效访问数据结构的方法。
例如：我们需要在 lua 和 C 中共享一个 vector 3 结构，有两种实现方法：一、把 C struct 实现为 lua 中的 userdata ，然后给 userdata 加上 metatable 以供 lua 中访问内部数据；二、在 lua 中使用一个 table 实现这个 vector3 结构，类似 { x = 0.0 , y = 0.0, z = 0.0 } 这样；然后在 C 里通过 c api (lua_rawget/lua_gettable/lua_getfield) 来访问里面的数据。
前一种方法会导致在 Lua 中访问成本加大、而后一种方法增加的是 C 中访问数据的成本。如果我们只在少数性能敏感的地方通过 C 去操作数据结构，那么第二种方法看起来更简单灵活一些。这样，不需要 C 介入的地方，是没有额外开销的。毕竟、通过 metamethod 索引 userdata 的成本比直接索引一个普通的 table 要重的多。
这两个月，我的主要工作是跟进公司内一个 MMORPG 项目，做一些代码审查提出改进意见的工作。
在数月前，项目经理反应程序不太稳定，经常出一些错误，虽然马上就可以改好，但是随着开发工作推进，不断有新的 bug 产生。我在浏览了客户端的代码后，希望修改一下客户端的 UI 框架以及消息分发机制等，期望可以减少以后的 bug 出生概率。由于开发工作不可能停下来重构，所以这相当于给飞行中的飞机换引擎，做起来需要非常小心，逐步迭代。
工作做了不少，其中一个小东西我觉得值得拿出来写写。
我希望 UI 部分可以严格遵守 MVC 模式来实现。其实道理都明白，但实际操作的时候，大部分人又会把这块东西实现得不伦不类。撇开各种条条框框，纸上谈兵的各种模式，例如 MVC MVP MVVM 这些玩意，我认为核心问题不在于 M 和 V 大家分不清楚，而是 M 和 V 产生联系的时候，到底应该怎么办。联系它们的是 C 还是 P 或是 VM 都只为解决一个问题：把 M 和 V 解耦。
昨天在 review 我公司一个正在开发的项目客户端代码时，发现了一些坏味道。
客户端框架创建了一个简单的对象系统，用来组织客户端用到的对象。这些对象通常是有层级关系的，顶层对象放在一个全局集里，方便遍历。通常，每帧需要更新这些对象，处理事件等等。
顶层每个对象下，还拥有一些不同类别的子对象，最终成为一个森林结构，森林里每个根对象都是一颗树。对象间有时有一些引用关系，比如，一个对象可以跟随另一个对象移动，这个跟随就不是拥有关系。
这种设计方法或模式，是非常常见的。但是在实现手法上，我闻到了一丝坏味道。
很多使用 Unity3D 开发的项目，都不太喜欢 C# 这门开发语言，对于游戏开发很多人还是更喜欢 Lua 一些。而 Lua 作为一门嵌入式语言，嵌入别的宿主中正是它说擅长的事。这些年，我见过许多人都做过 U3D 的 Lua 嵌入方案。比如我公司的阿楠同学用纯 C# 实现了一个 Lua 5.2 （用于在 U3D web 控件中嵌入 Lua 语言的 UniLua ）；还有 ulua slua wlua plua xlua ... 数不胜数。我猜测，a-z 这 26 个字母早就用完了。
上面提到的项目的作者不少是我很熟悉的朋友，我们公司现在的 U3D 游戏也由同事自己实现了一套差不多的东西。所以我曾了解过这些方案。但我一直觉得这些方案要么做的过于繁琐，要么有些细节上不太完备，总是手痒想按自己的想法搞搞看。
Mono 和 C 通讯使用 P/Invoke ，用起来不算麻烦，但是要小心暗地里做的 Marshal 的代价，特别是对象传递时装箱拆箱的成本。Lua 和 C 通讯有一套完善的 C API ，但完全正确使用并不容易。核心难点是 Mono 和 Lua 各有一套自己的异常机制，让它们协调工作必须很小心的封装两个语言的边界，不要让异常漏出去。我在 2015 年写过一篇 Blog 做过相关讨论 。
我认为简单且完备的 Mono / Lua 交互方案是这样的：
很多项目采用 lua 的一大原因是 lua 可以方便的做热更新。
你可以在不中断进程运行的情况下，把修改过的代码塞到进程中，让随后的过程运行新版本的代码。这得益于 lua 的 function 是 first class 对象，换掉代码不过是在让相应的变量指向新的 function 对象而已。
但也正因为 lua 的这种灵活性，想把热更新代码这件事做的通用，且 100% 做对，又几乎是不太可能的。
首先，你很难准确的定义出，什么叫做更新，哪些数据需要保留，哪些需要替换成新版本。光从源代码和运行时的元信息上去分析是远远不够的。
lua 只有一种通用数据结构 table ，这方便了我们做数据更新；但同时也制造了一些模糊性难题。比如，如果在代码中有一些常量配置数据表，写死在源代码中，通常你是希望跟着新版本一起更新的；而有一些表，记录着运行时的状态，你又不希望在代码更新后状态清空。
所以一般做热更新方案的时候，都会人为加一些约束，在遵循约束条件的前提上，尽量让更新符合预期。
最近一段时间在帮公司一个项目组的客户端 review 代码。
我们的所有项目，无论渲染底层是用的 ejoy2d 还是 Unity3d ，实际开发的时候都基本是使用 lua 。所以开发人员日常工作基本是在和 Lua 打交道。
虽然我个人挺反感围绕着调试的开发方式，也就是不断的在测试、试错，纠正的循环中奔波。我认为好的程序应该努力在编写的过程中，在头脑中排错；在预感到坏味道时，就赶快重写。而坏味道通常指代码陷入了复杂度太高的境地，无法一眼看出潜在的问题。对付复杂度最好的武器是简化代码，而非调试器。
在真正遇到 bug 时，应该仔细浏览代码，设想各种出错的可能。而不是将错误的代码运行起来，查看运行中的状态变化。
话说回来，看到项目组的同学真的碰到 bug 时，不断的启动 Unity 客户端，把时间浪费在等待那几行 debug log 上，我觉得效率还是很低。必要的调试工具应该能提升一些开发效率的。
lua 官方提供了完善的 debug api 可以查询所有的信息；但并没有一套官方的调试工具。我都不记得是第几次写调试工具了。至少在这个 blog 上就记录了好几次。最近的一次是 3 年前 。
今天有同学跟我讨论了一下最近发现的一个 bug ，我觉得挺有意思的。
需求是这样的：
我们的系统中，有一些数据是从外存（数据库）加载进来的，由于性能考虑，并不需要每次修改这些数据就写回外存。希望在数据变冷后，定期落地即可。
典型的场景是一个 cache 模块，cache 的是一些玩家的业务数据，可以通过 uuid 从数据库索引到。一旦业务需要访问玩家数据，cache 模块会从数据库加载对应数据，然后把数据表交出去。当业务再次需要这些数据的时候，cache 模块一旦发现数据存在于 cache 中，就直接交给玩家。
cache 模块还希望在数据很久没有被业务访问时，将这些数据写回数据库。
我们的系统是基于 lua 构建的，数据 cache 模块和修改这些数据的逻辑在同一个 vm 里。难点在于，修改数据的业务逻辑是可以长期持有数据的，cache 模块需要正确感知这点。
今天在公司群里，Net bug 同学提出了一个问题，围绕这个问题大家展开了一系列讨论。讨论中谈及了 lua 中的一个常见的模式：property table ，我觉得挺有意思，记录一下。
最初的问题是：当一个对象的某些属性并不常用，希望做惰性初始化的话，应该怎么实现。
我认为，property table 是一个很符合这个案例的常见模式。
比如，对象 f 有三个可能的成员 a b c ，我们可以不把 f.a f.b f.c 记录在 f 这个 table 里，而是额外有三张大表，a b c 。利用 metatable ，可以在访问 f.a 的时候，实际访问的是 a[f] 。也就是说，所有同类对象的 a 属性，都是从 a 这张表里访问的。
a 这张表的 key 就是对象，value 是对象对应的 a 属性值。
Lua 的 table 可以做数组用，但是前提是数组里不能有空洞。也就是不能在数组里保存 nil ，否则取长度和迭代的行为都是不确定的。
能不能用比较小的额外代价在 Lua 中实现一个支持空洞的数组呢？
首先，我们定义一下，带空洞的 array 的正确行为应该是怎样的：
数组只能用正整数做 key ，设置其它 key 会抛出 error 。
可以用 pairs 迭代数组，和普通的 table 一样，迭代器会跳过那些值为 nil 的键值对。但要求迭代器一定从 1 开始从小到大按次序迭代。
用取长度 (#) 操作符，可以正确的返回数组的大小，即最大一个正整数 key 。
ipairs 的行为不变，会在第一个 nil 处停下来。
在 Lua 5.2 之后的版本，约定了在元表中可以给出一个 __pairs 方法，而 lua 的基础库 pairs 会使用这个元方法来迭代一个对象。
Lua 5.3 之后的版本，取消了 lua 5.2 中的 __ipairs 约定，而统一使用 lua_geti 来访问整数为索引的数组。
可惜的是，许多 lua 序列化库对此支持的并不好。今天我在改进 bson 的序列化库时，重新考虑了这个问题，看看这个序列化过程怎么做，才能更好的支持 lua 5.3 以后的约定。
今天花了一天尝试给 lua vm 做了一点优化：
现在 lua 的函数原型里保留有一张常量表，引用了 string ，number ，nil ，boolean 类型的常量。
table 是不能为常量的，所以当你想迭代一个常量数组的时候，
for _, v in ipairs { "one", "two", "three" } do
其实每次都会临时构建一张表，并依次插入 "one", "two", "three" 。
或者你想返回一个常量构成的表：
function foo()
return { x=1, y=2 }
end
每次 foo 函数都会为返回值重新构建 table 。
无论是客户端还是服务器，把 lua 作为嵌入语言使用的时候，都在某种程度上希望把 lua 脚本做多线程使用。也就是你的业务逻辑很可能有多条业务线索，而你希望把它们跑在同一个 lua vm 里。
lua 的 coroutine 可以很好的模拟出线程。事实上，lua 自己也把 coroutine 对象叫做 thread 类型。
最近我在反思 skynet 的 lua 封装时，想到我们的主线程是不可以调用阻塞 api 的限制。即在主干代码中，不可以直接 yield 。我认为可以换一种更好（而且可能更简洁）的封装形式来绕过这个限制，且能简化许多其它部分的代码。
下面介绍一下我的新想法，它不仅可以用于 skynet 也应该能推广到一切 lua 的嵌入式应用（由你自己来编写 host 代码的应用，比如客户端应用）：
skynet 本质上只是一个消息分发器，以服务为单位，给每个服务一个独立的 id ，可以从任意服务向另一个服务发送消息。
在此基础上，我们在服务中接入 Lua 虚拟机，并将消息收发的 api 封装成 lua 模块。目前用 lua 编写的服务在最底层只有一个入口，就是接收并处理一条 skynet 框架转发过来的消息。我们可以通过 skynet.core.callback （这是一个内部 API ，用 C 编写，通常由 skynet.start 调用）把一个 lua 函数设置到所属的服务模块中。每个服务必须设置，且只能设置一个回调函数。这个回调函数在每次收到一条消息时，接收 5 个参数：消息类型、消息指针、消息长度、消息 session 、消息来源。
消息大致分两大类，一类是别人对你发起的请求，一类是你过去对外的请求收到的回应。无论是哪类，都是通过同一个回调函数进入。
在实际使用 skynet 时，你可以直接使用 rpc 的语法，向外部服务发起一个远程调用，等对方发送了回应消息后，逻辑接着走下去。那么，框架是如何把回调函数的模式转换为阻塞 API 调用的形式呢？
这多亏了 lua 支持 coroutine 。可以让一段代码运行了一半时挂起，在之后合适的时候在继续运行。
今天同事提了个需求，他希望可以给部分 lua 代码（由策划编写）做一个沙盒关起来。在 lua 里做沙盒很容易，只需要控制函数的环境就可以了。不过另一个附加需求是，这些代码还可以直接利用 require 加载。
而我们又不想去修改系统的 api 接口，那么怎么做到这点呢？
首先, 我希望使用的时候看起来像这样：
local xxx = require "xxx" (myEnv)
和传统的 require 用法不同，可以在后面追加一个参数 myEnv 。这样的话，每次 xxx 模块被 require 时，它其实被重复运行一次，但会绑定不同的 _ENV 。
其次，既然模块会被反复初始化，那么我们甚至还可以约定，每个这种沙盒封装的模块还可以接收 require 的传入的额外参数。
lua 中 40 字节以下的字符串会被内部化到一张表中，这张表挂在 global state 结构下。对于短字符串，相同的串在同一虚拟机上只会存在一份。
在 skynet 中，有大量的 lua vm ，它们很可能加载同一份 lua 代码。所以我之前改造过一次 lua 虚拟机，[让它们可以共享 Proto] 。这样可以加快多个虚拟机初始化的速度，并减少一些内存占用。
但是，共享 Proto 仅仅只完成了一半的工作。因为一段 lua 代码有一很大一部分包含了很多字符串常量。而这些常量是无法通过共享 Proto 完成的。之前的方案是在 clone function 的时候复制一份字符串常量。
或许，我们还可以做的更进一步。只需要让所有的 lua vm 共享一张短字符串表。
Lua 是一门嵌入式语言，和 host 的联动非常重要。Lua 使用 userdata 来保存 host 里的数据，userdata 非常强大，可以有 metatable 还可以关联一个 uservalue ，可以封装一切 C/C++ 对象，非常强大。但有的时候却稍显不足，似乎缺了点什么，导致一些简单的需求要用很繁琐的方式解决。
有个想法想过很久，今天动了念头用英文写了一遍投递到 lua 邮件列表里去了。
那就是，如果我们可以给 userdata 的值关联一个整数，而不是把 uservalue 关联到 userdata 的对象里那样，可以简化很多事情。
从周末开始, 我一直在忙一个想法。我希望给 skynet 中的 lua 服务定制一个内存分配器。
倒不是为了提升性能。如果可以单独为每个 lua vm 配置一个内存分配器，自己调用 mmap 映射虚拟内存，就可以为独立的服务制作快照了。这样可以随时 fork 出子进程，只保留关心的 vm 的内存快照。主要可以有三个用途：
可以在快照上做序列化，并把结果返还父进程。通常做序列化有一定的时间代价，如果想定期保存的话，这个代码很可能导致服务暂停。
可以利用快照监控检查泄露。定期做快照相比较，就能找到累积的对象。我曾经做过这样的工具 。
可以在镜像上对快照做一些调试工作而不会影响主进程。
今天有人转了个知乎上的帖子给我看：Lua 5.3为何很慢？该不该升级？ 。
首先，我不认为 10% 的性能差异能够称的上很大，和 10% 的性能下降相比，程序更清晰稳定、功能更完备（不是指功能多，而是指对各种边界条件处理的更好）要重要的多。毕竟，让 CPU 提升 10% 的性能很容易。
其次，在实际项目中，和简单的测试脚本不同，我很难观察到 10% 的差异。（我们的服务器用过 lua 5.2 和 lua 5.3 两个版本，很难从线上压力上感知到性能差别）。
如果你真的用那些简单的测试脚本做一个比较，lua 5.1 比它的前一个版本 lua 5.0 要慢得多。差别或许比 lua 5.1 到 5.3 还要大。而为什么很少人关心这个，去用回 5.0 呢？说到底还是因为 luajit 导致的 lua 社区的分裂，让 lua 5.1 这个中间版本变成了另一个 lua 而已。
我的硬盘上一直留有从 lua 4.0 开始几乎每个 lua 小版本的源代码副本。而近十年来，一直都在跟进 lua 的源码变迁，所以我对 lua 的每次修改都或多或少有一些印象。下面谈谈我对这个新版本越来越慢的一点个人看法吧。
Lua 作为一门嵌入式语言，提供了完备的 C API 供 Lua 代码和宿主程序交互，当然，宿主语言最好是 C 或 C++ 。如果是其它语言，比如最近两年流行的在 mono 环境嵌入 Lua 另当别论。
正确将 Lua 嵌入是不太容易做对的事情，很多刚接触 Lua 的人都容易犯错误。好在做这种语言桥接工作都是项目开始阶段的设计者做的，不必人人学会，所以只要有熟悉 Lua 的人来搞，犯错误的危害不会太大。而且即使做的有问题，日后修改也比较容易。这篇 blog 主要就是谈谈，最容易做错的位置，和一些正确（但看起来麻烦）的实现方法。
最容易忽略的是 Lua 中 error 的处理。
Lua 中叫 error ，再其它语言中叫 exception ，后面姑且全部称为异常吧。
如果你认真读过 Lua 的手册。 就会发现，在所有 C API 那里，都注明了这个 API 是否会抛出异常。比方说 lua_tostring 就标注的是 [-0, +1, e] ，有可能抛出异常（是不是和你的直觉不同？）；但 lua_pushlightuserdata 则不会。
Lua 的异常应该由 lua_pcall 或 lua_resume 来捕获，所以当你调用 C API 的时候，应该确保在 C 的调用层次上，处于某次 lua_pcall 或 lua_resume 中。所以，即使是常见的创建 Lua 虚拟机的简单几行代码，都有可能写错。比如：
lua_State *L = luaL_newstate();
if (L) {
luaL_openlibs(L);
}
这样写就是考虑不周的。因为 luaL_openlibs(L) 可能抛出异常，这样便没有捕获它。
2021 年 2 月 7 日：这个库已经删除，用新的实现代替了。见：https://blog.codingnow.com/2021/02/ltask.html
写这个东西的起源是，前段时间我们的平台组面试了一个同学，他最近一个作品叫做 luajit.io 。面试完了后，他专门找我聊了几个小时他的这个项目。他的核心想法是基于 luajit 做一个 web server ，和 ngx_lua 类似，但撇开 nginx 。当时他给我抱怨了许多 luajit 的问题，但是基于性能考虑又不想放弃 luajit 而转用 lua 。
我当时的建议是，不要把 lua/luajit 作为嵌入语言而自己写 host 程序，而是想办法做成供 lua 使用的库。这样发展的余地要大很多，也就不必局限于用户使用 lua 还是 luajit 了。没有这么做有很多原因是设计一个库比设计一个 host 程序要麻烦的多，不过麻烦归麻烦，其实还是可以做一下的，所以我就自己动手试了一下。
Lua 的多任务库有很多，有兴趣的同学 可以参考一下 lua user wiki 。
最近，我们的合作方 陌陌 带了他们的一个 CP 到我们公司咨询一下 skynet 做 mmo 游戏项目中遇到的一些问题。因为他们即将上线一款 MMO ，在压力测试环节暴露了许多问题。虽然经过我们的分析，有很多问题出在他们的压力测试程序本身编写的 bug ，但同时也暴露出服务器的设计问题。
核心问题是，他们在实现 mmo 服务器时，虽然使用了 skynet 框架，但却把所有的业务逻辑都放在了同一个 lua 服务中，也就是一切都运行在一个 lua states 里。这样，几乎就没能利用上 skynet 原本想提供的东西。压力是一定存在的。
我花了一下午探讨了应该如何设计一个 MMO 的服务器。下面记录一下：
在 skynet 中，有一个叫 monitor 的内部模块，它会监测是否有服务可能陷入了死循环。
工作原理是这样的：每次处理一个服务的一个消息时，都会在一个和服务相关的全局变量处自增 1 。而 monitor 是一个独立线程，它每隔一小段时间（5 秒左右）都检测一下所有的工作线程，看有没有长期没有自增的，若有就认为其正在处理的消息可能陷入死循环了。
而发现这种异常情况后，skynet 能做的也仅仅是输出一行 log 。它无法从外部中断消息处理过程，而死循环的服务，将永久占据一个核心，让系统整体性能下降。
采用 skynet 的 kill 指令是无法杀掉死循环的服务的。
当服务用 lua 编写时，我们则有可能做多一点工作。
一直有人问，如何调试 skynet 构建的服务。
我的简单答案是，仔细 review 代码，加 log 输出。长一点的答案是，尽量熟悉 skynet 的构造，充分利用预留的监控接口，自己编写工具辅助调试。
之前的好多年，我也写过很多 lua 的调试器，这里就不一一翻旧帖了。今天要说的是，我最终还是计划加入 1.0 正式版的调试控制台。
也就是单步跟踪调试单个 lua coroutine 的能力。这对许多新手来说是个学走路的拐杖，虽然有人一辈子都扔不掉。
最近想给 skynet 加一个在线调试器，方便调试 Lua 编写的服务。
Lua 本身没有提供现成的调试器，但有功能完备的 debug api 。通常、我们可以在代码中插入 debug.debug() 就可以进入一个交互环境，输入任何 Lua 指令。当然，你也可以在 debug hook 里调用它。
但这种交互方式有一个缺点：lua 直接用 load 翻译输入的文本，转译为一个 lua 函数并运行。这注定了这个输入的代码中不能直接访问到上下文的局部变量和 upvalue 。
如果想读写上下文中的局部变量或 upvalue ，还得使用 debug.getlocal 等函数。这无疑是相当麻烦的。
最近在慢慢把公司的几个项目从 Lua 5.2 迁移到 Lua 5.3 ，为发布 skynet 1.0 alpha 版做准备。
在更新代码时发现了一些注意点，罗列一下：
Lua 5.3 去掉了关于 unsigned 等的 api ，现在全部用 lua_Integer 类型了。这些只需要换掉 api ，加上强制转换即可。通常不会有什么问题。
最需要细致 review 代码升级的是和序列化相关的库。在 skynet 里是序列化库、sproto、bson 等。我们还用到了 protobuffer ，也和序列化有关。
这是因为，Lua 5.3 提供了整型支持，而序列化工作通常需要区分浮点和整数分开处理。json 这种文本方式则不需要，同样还有 redis 的通讯协议也是如此。
过去判断一个 number 是浮点还是整数，需要用 lua_tonumber 与 lua_tointeger 各取一份做比较。虽然到了 Lua 5.3 这种代码理论上可以不用改动，但正确的方法应该是使用 lua_isinteger 。
Lua 5.3 正式发布了。
我的三个计划就需要开动了。
计划一：把文档重新翻译一遍。
八年前，我翻译了 Lua 5.1 的中文手册。今天我想再从头做一次翻译工作，借这个机会可以理一遍（以及更新）和 Lua 相关的知识。这次，我选择在 github 上做这个工作，而不是闷头搞完了再发布。
这个项目在 https://github.com/cloudwu/lua53doc ，如果你只是想阅读最终的手册，可以访问这里。如果发现了错别字，不用给我留言，你只需要在 github 上提个 PR ，我会合并的。
今天下午开始的，目前译完了 readme 、目录页、和正文的很少一部分。我估计需要全职至少 3 个工作日才能全部译完。这次我选择尽量把英文术语翻译成中文，对于我按个人喜好选择的译词，我专门列在一个页面中。
在 2015 年的新年里，Lua 5.3 发布了 rc3 版。
如果回顾 Lua 5.2 的发布历史，Lua 5.2 的 final 版是在 rc8 之后的 2011 年 12 月 17 日发布的，距离 rc1 的发布日 2011 年 11 月 24 日过去不到 1 个月。我们有理由相信正式版不远了。( 5.3 的 rc1 是 2014 年 12 月 17 日发布的）
这次升级对 Lua 语言层面的影响非常的小，但新增加的 int64 支持，以及 string pack 、utf8 库对开发帮助很大。所以我强烈建议正在使用 Lua 5.2 的项目尽快升级到 5.3 。相对而言，当初 5.1 向 5.2 升级的时候就痛苦的多（去掉了 setfenv ，增加了 _ENV）。
我计划在 Lua 5.3 正式发布后，将 skynet 内置的 Lua 版本升级到 5.3 ，然后着手进行 skynet 1.0 的发布工作。
我相信至少在国内的游戏策划圈, Excel 是每天必不可少的存在。倒不是因为要用它制作数值表格，一切文档最终都一定是用 Excel 写的。但作为一个程序员，我相当的痛恨 Excel 文件，就好像我当初痛恨 word 一样。只有几个字就不要保存成 doc 文件啦，可现在已经没有人用 word 了，大家全转去 Excel 了。如果有可能，策划一定愿意在单元格里写脚本的，这样可以将重点标红。
提取 Excel 中的文字信息并不复杂，但真正的麻烦在于 Excel 文件对版本管理工具是极不友好的。甚至你打开一次 Excel 文件再保存关闭，也会生成一个完全不同的新版本。这是因为，文件中记录了最后修改的时间（是的，Excel 不信任文件系统里的时间）；还有激活的单元格是哪一个。在这种环境下，多人协作的版本控制工具用起来绝对是一个悲剧。
我大概花了一周时间来试图解决一系列问题。结果不算成功，也不算失败。这里记录一下上周踩过的坑。
问题源于我们的项目中，策划把一切他们能生产的东西都记在了诸多的 excel 表格里。当然，和上世纪的程序员一样，大家都尽量自己维护自己的那块文件，所以即使在版本管理工具下，也基本没有冲突。但是总有那么 1% 的机会，几个人会修改同一张表格的，尤其在项目压力大时，往往实现功能的程序也会打开表格对里面的数据做一些修改。在版本控制工具下，冲突就在所难免了。尤其是我们刚刚让策划从 svn 迁移到 git 下，git 的工作流的复杂性很容易让策划的脑子不够用了（实际上受 Excel 文件格式限制，他们也只需要一个版本备份工具，其它本来就是多余的）。我开始动念头来解决问题。
首先，xlsx 文件其实是一个标准 zip 压缩包，里面打包了一系列 xml 文件。如果仅仅是需要一个文本格式，那么只需要把包解开，用一种非压缩的形式重新打包即可。
对于一些嵌入的图片，只需要用 base64 编码。由于嵌入表格的图片多半不会修改，所以并不会造成版本间的差异。
一开始，我以为这项工作两小时就能搞定，事后发现，太天真了。
我写了一个 lua 的小程序，可以读出 zip 包里的文件，对文件名排序，然后按文件名/内容的次序依次把文件连在一起形成一个大文本文件（其中的２进制内容使用 base64 编码）。这样处理后，xlsx 文件基本就是一个文本文件了。为了对版本管理工具友好，我对 xml 里的标签后增加了适当的分行。这样处理以后，版本管理工具基本能识别出表格数据每个版本的差异。
第２步，可以动手消除一些对版本有影响却对我们没有意义的数据段。比如文件的最后修改时间、激活的单元格等。这样、如果打开一个 excel 文件，保存后就不会产生差异。
那么，这是一个新的文件格式。怎么让 Excel （或 wps 等兼容产品）打开它编辑呢？
虽然第一反应是给 excel 写一个插件。但我知道拿不是一两个小时可以搞定的。所以我选择了一条弯路。写了一个脚本，可以生成一个临时目录/文件，在用户想打开一个自定义格式文件时，先转换为标准的 xlsx 临时文件，让关联的软件（excel 或 wps 等）编辑它。我们可以监控这个文件的变更时间，来即使把临时文件转换回去。当这个临时文件可写时，就表示已经停止编辑这个文件了（excel 对打开的文件有文件锁定）。这时，可以删除临时文件。
让自定义文件格式关联到这个脚本（我用 lua 编写的十多行程序），策划就可以直接双击自定义格式文件编辑了。
skynet 目前的 api 提供的偏底层，由于一些历史原因，某些 api 的设计也比较奇怪。（比如 skynet.ret 是不对返回数据打包的）
我想针对一些最常见的应用环境重新给出一套更简单的 api ，如果按固定模式来编写 skynet 的内部服务会简单的多。
这就是这两天实现的 snax 模块。今天我已经将其提交到 github 的 snax 分支上，如果没有明显的问题，将合并入主干。
snax 仅解决一个简单的需求：编写一个 skynet 内部服务，处理发送给它的消息。snax 并不会取代 skynet 原有的 api ，只是方便实现这类简单需求而已。
有时候我们的项目需要大量的配置表(尤其是网络游戏) 。因为主要用 lua 做开发，我们倾向于直接用 lua table 保存这些配置常量。
海量的数据有两个问题：
这些配置数据在运行期是不变的，但树型结构复杂，放在 lua 虚拟机内会生成大量的 gc object ，拖慢 lua 的垃圾收集器。因为每次扫描都需要把所有配置数据都标记一遍。
在服务器端，我们使用 skynet 框架，会启动数千个 lua 虚拟机。如果每个虚拟机都加载一份配置信息，会带来大量的内存浪费。
Lua 的 API 设计的非常精良，整个 lua 核心库把内存管理都托管给了 lua_Alloc 这个用户注入的函数。任何时候在发生内存不足，lua 的 api 都可以正确处理异常。
考虑一下 lua_newtable 或是 lua_pushlstring 这些 api ，它们都需要创建新的 gcobject ，这些时候如果发生 lua_Alloc 分配不出内存怎么办？这些 api 可都是无返回值的。
lua 的行为是：抛出一个内存错误，如果外界没能捕获这个错误，则触发 panic 函数。
在编写将 lua 嵌入到宿主程序中的一个常见的错误是：
先用 lua_newstate 创建出一个 lua 虚拟机，然后直接调用 luaL_openlibs 等函数初始化它。如果你希望你的代码足够严谨，就必须了解，初始化的过程是有可能遇到内存申请不到的情况的。
正确的做法在 lua 自带的解释器实现中有一个很好的范例：你可以写一个 lua c function ，在里面做后续对 lua_State 的操作。在 lua_newstate 后，立刻 lua_pcall 这个 C 函数，而不是直接调用它。这样，所有的内存异常都会被这次 pcall 捕获住。
btw, 早期版本的 lua 有一个 lua_cpcall 函数，自从 lua 支持 light c function 后就去掉了这个 api 。
在 skynet 这种应用中，同一个系统进程里很轻易的就会创建数千个 lua 虚拟机。lua 虚拟机本身的开销很小，在不加载任何库（包括基础库）时，仅几百字节。但是，实际应用时，还需要加载各种库。
在 lua 虚拟机中加载 C 语言编写的库，同一进程中只会存在一份 C 函数原型。但 lua 编写的库则需要在每个虚拟机中创建一份拷贝。当有几千个虚拟机运行着同一份脚本时，这个浪费是巨大的。
我们知道，lua 里的 function 是 first-class 类型的。lua 把函数称为 closure ，它其实是函数原型 proto 和绑定在上面的 upvalue 的复合体。对于 Lua 实现的函数，即使没有绑定 upvalue ，我们在语言层面看到的 function 依然是一个 closure ，只不过其 upvalue 数量为 0 罢了。
btw, 用 C 编写的 function 不同：不绑定 upvalue 的 C function 被称为 light C function ，可视为只有原型的函数。
如果函数的实现是一致的，那么函数原型就也是一致的。无论你的进程中开启了多少个 lua 虚拟机，它们只要跑着一样的代码，那么用到的函数原型也应该是一样的。只不过用 C 编写的函数原型可以在进程的代码段只存在一份，而 Lua 编写的函数原型由于种种原因必须逐个复制到独立的虚拟机数据空间中。
我们现在的手游完全用 Lua 开发，这就有了调试的需要。
今年曾写过一个 lua 代码跟踪器，主要是用于服务器开发。服务器程序不适合完全 stop the world 慢慢调试，以输出 log 为主。但现在在客户端，那么一个类 gdb 的调试环境更好一些。
lua 的调试器在我还在网易时就做过 。从网易出来后没带代码，需要用就要重新写了。好在 lua 的 debug 接口非常全，今天花了 2 个小时就重新实现了一个简陋的雏形。
以前我在 blog 写过 Lua 5.1 的 gc 代码分析 ，而 Lua 5.2 对这部分代码改动颇多，暂时也没有精力更新这个系列，先挑重点写吧。
Lua 5.2 的 GC 的最大改进是增加了一种叫 generational 的模式，Lua 的官方文档里是这样解释的。
As an experimental feature in Lua 5.2, you can change the collector's operation mode from incremental to generational. A generational collector assumes that most objects die young, and therefore it traverses only young (recently created) objects. This behavior can reduce the time used by the collector, but also increases memory usage (as old dead objects may accumulate). To mitigate this second problem, from time to time the generational collector performs a full collection. Remember that this is an experimental feature; you are welcome to try it, but check your gains.
根据 Lua 文档中的说法，lightuserdata 比 fulluserdata 要廉价一些。那么，其中的区别在哪里呢？
空间开销上，fulluserdata 是一个 GC 对象，所以比 lightuserdata 要多消耗一点内存，这点内存往往对程序不造成太大的影响。
时间开销上，fulluserdata 在访问它时和 lightuserdata 并无太大区别，它们都只能通过元方法才能在 Lua 中使用。所有 lightuserdata 共用一个元表，不如 fulluserdata 灵活，在元表访问效率上却是几乎相同的。对程序性能有影响的部分在于它们对 GC 环节的开销不同。
fulluserdata 本身是一个 GC 对象，所以在扫描的时候要复杂一些。它可能有附带的 uservalue 需要扫描，但不设置 uservalue 几乎就没有额外的扫描开销了。当 fulluserdata 有 gc 元方法后，就给 GC 流程增加了额外的负担。GC 模块需要额外记录一个链表来串接起所有有 gc 元方法的对象，推迟到 gc 的最后环节依次调用。
对于对延迟相当敏感的游戏程序来说，最容易造成运行过程中瞬间延迟增加，却又很难控制的部分就是 GC 了。所以我们在开发中经常需要关注怎样合理的使用 Lua 避免 GC 的负担过大。
这几天在 lua 和 luajit 的邮件列表上有人讨论 coroutine 的再利用问题。
前几天有个用 skynet 的同学给我写了封邮件，说他的 skynet 服务在产生了 6 万次 timeout 后，内存上升到了 50M 直到 gc 才下降。
这些让我重新考虑 skynet 的消息处理模块。skynet 对每条消息的相应都产生了一个新的 coroutine ，这样才能在消息处理流程中，可以方便的切换出去让调度器调度。诸如 RPC/ socket 读写这些 api 才能在用起来看成是同步调用，却在实现上不阻塞线程。
读源码可知，lua 的 coroutine 非常轻量（luajit 的略重）。但依旧有一些代价。频繁的动态生成 coroutine 对象也会对 gc 造成一定的负担。所以我今天花了一点时间优化了这个问题。
简单说，就是用自己写的 co_create 函数替换掉 coroutine.create 来构建 coroutine 。在原来的主函数上包裹一层。主函数运行完后，抛出一个 EXIT 消息表示主函数运行完毕。并把自己放到池中。如果池中有可利用的旧 coroutine ，则可以传入新的主函数重新利用之。
为了简化设计，如果 coroutine 中抛出异常，就废弃掉这个 coroutine 不再重复利用。为了防止 coroutine 池引用了死对象，需要在主函数运行完后，把主函数引用清空，等待替换。
具体实现参见这个 patch 。
ps. coroutine poll 故意没实现成弱表，而是在相应 debug GC 消息时再主动清空。
前几天在做 Hive 的 socket 库的时候， 遇到一个问题很典型，我记得不是第一次遇到了。值得记录一下。
socket 底层有一个 poll 的 api ，通过 epoll 或 kqueue 或 select 取得一系列的事件。用 lua 怎么封装它呢?
一个比较直接的想法是注入一个 callback function ，对于每个事件回调一个 lua 函数。但这容易引起许多复杂的问题。因为回调函数很不可控，内部可能抛出异常，也可能引起函数重入，或是做了一些你不喜欢去做的事情。
如果面面俱到，就会让原本 C/Lua 边界的性能问题更加恶化。
所以，我采用了方案二：把所有事件以及相关数据全部返回，让后续的 Lua 代码去处理 C 层获取的所有事件。
这个方案也容易造成性能问题，那就是临时构件复杂数据结构，对 Lua VM 的 GC 造成的压力。
上个周末我一直在想，经过一年多在 skynet 上的开发，我已经有许多相关经验了。如果没有早期 erlang 版本的历史包袱以及刚开始设计 skynet 时的经验不足，去掉那些不必要的特性后的 skynet 应该是怎样的。
一个精简过代码的 skynet 不需要支持 Lua 之外的语言和通讯协议。如果某个服务的性能很关键，那么可以用 C 编写一个 Lua 库，只让 Lua 做消息分发。如果需要发送自定义协议的消息，可以把这个消息打包为一个 C 结构，然后把 C 结构指针编码在发送的消息中。
skynet 的内部控制指令全部可以移到一个系统服务中，用 Lua 编写。
跨机支持不是必要的。如果需要在多个进程/机器上运行多份协同工作，可以通过编写一个跨机通讯的服务来完成。虽然会增加一个间接层使跨进程通讯代价更大，但是可以简化许多代码。
广播也不是基础设施，直接用循环发送复制的消息即可。为了必要过大的消息在广播过程中反复拷贝，可以把需要广播的消息先打包为 C 对象，然后仅广播这个 C 对象的指针即可。
唔，我知道有人已经做了 MongoDB 的 lua driver ，比如这个 。但我不想仅仅是对 C++ API 的封装，而想从协议层做起，这样日后可以方便改为异步模型，也好整合到 skynet 中去。
这里还有一份纯 Lua 的实现，是从协议层做的封装。但有几个问题，一是依赖 lua-socket 库，二是纯 lua 实现不如 C 库性能好，三是特性没有支持完整。
我曾经想在 C Driver 的基础上做封装。做的过程中发现 c driver 代码质量不高，且特性支持不完整，最终我考虑自己从协议层开始重新做一份。
在 bson 的官方网站上链接了一个纯 Lua 实现的 bson 库，但是实现的不完整。
我用 C 实现了一个 Lua bson 库。
bson 是为 MongoDB 设计的结构化数据序列化协议，所以有很多设定是为 mongodb 服务的，如果单用于序列化结构化数据，那么那些不一定要实现。但我写这个的最终目的是做一个 lua 的 mongo driver ，所以就实现的比较完整了。
bson 结构中，有一些固定长度的字段，修改它们不必重新编码。这在 mongDB 的通讯协议中非常有用，所以我也加了对应的接口。还有许多特性可能会有用，比如把两个 bson document 连接成一个之类的，等我在写 mongoDB driver 的时候，视情况实现。
2014 : 3 月 12 日补充
因为 mongo 对有些 bson 文档要求 key 的次序, 而 lua 的 table 是无序的。所以增加了 bson.encode_order 按次序打包 document 。
最近思考了给 Lua 写 C 扩展的另一个问题。
我曾经总结过几种 Lua C 库中 C/C++ 对象的生命期管理问题 。最近想到另一个方案，虽然实现后并没有用到项目里，但值得记录一下。
Lua 没有 RAII ，一切对象的回收是依赖 GC 的。封装 C/C++ 对象则一般用 userdata 。userdata 比较重，作为临时对象使用总觉得有点别扭。比如封装 matrix 对象，如果我们为每个 matrix 对象都生成一个 userdata ，那么一些临时的 matrix 对象就会一直推迟到 GC 发生的时候才回收。而在 C/C++ 这样的语言中，临时对象通常是在离开调用层次时自动释放的。
对于某些 C 和 Lua 混合的业务也有这样的问题。某些较长的业务流程，一部分环节由于性能原因使用 C 来实现，另一部分更适合直接用 Lua 。我们必须用 userdata 来交换中间状态。比如处理一个 C 层次上产生的数据包或 C 结构数据，交由 Lua 处理后，C 对象就没有必要再存在了。但处理过程中，Lua 代码则需要反复引用和处理它。
多数情况下，我们不用太考虑这两者间的差别。但这并不妨碍我去考虑有没有可能在 Lua 中模拟一套栈对象的管理机制。它可能是 GC 系统之外的一种对象生命期管理的选择。
最近听从同事建议想尝试一下 MongoDB 。
前年，图灵的同学送过我一本《MongoDB权威指南》 ，当时我花了两个晚上看完。我所有的认知就是这本书了。我们最近的合作项目 狂刃 也是用的 MongoDB ，最近封测阶段，关于数据库部分也出过许多问题。蜗牛同学在帮助成都的同学做调优，做了不少工作。总是能在办公室里听到关于 MongoDB 的话题。
我打算为 skynet 做一个 MongoDB 的 Driver 。
Skynet 默认是用 lua 做开发语言的。那么为什么不直接用 luamongo 呢？
因为 skynet 需要一个异步库，不希望一个 service 在做数据库操作的时候被阻塞住。那么，我们就不可能直接把 luamongo 作为库的形式提供给 lua 使用。
一个简单的方法是 skynet 目前对 redis 做的封装那样（当然，skynet 中的 redis 封装也是非阻塞的），提供一个独立的 service 去访问数据库，然后其它服务器向它发送异步请求。如果我直接使用 luamongo 就会出现一个问题：
我需要先把请求从 lua table 序列化，发送给和 mongoDB 交互的位置，反序列化后再把 lua table 打包成 bson 。获得 MongoDB 的反馈后，又需要逆向这个流程。这是非常低效的事情。如果我们可以直接让请求方生成 bson 对象，这样就可以直接把 bson 对象的指针发过到 交互模块就够了（ skynet 是单进程模型，可以在服务内直接交换 C 指针）。这就需要我定制一套 lua moogodb 的 driver 了。
最近有份工作是需要把 Lua 中的数据结构以某种特定的格式输出为文本的，所以就用到了 Lust 这是个代码生成工作的利器。
可能是用的人不多，所以还略显不完整。用的时候发现一些个小问题，原来以为是 bug，读了源代码后发现是个 feature 。但是觉得这个 feature 不太合理，就上 github 上留言。作者倒挺爽快，马上表示赞同并去掉了。
第 2 个是 luaffi 。这个东西原本是 luajit 的一部分，可好多人确是冲着 ffi 库去用 luajit 的。
luajit 目前尚有不少的局限性，比如内存只能用 32 位寻址，不支持 lua 5.2 的 api 等。另外，从稳定性上来说，也不如原版的 lua 更让人放心。
据我所之，我们合作的狂刃 的服务器端就为了 ffi 使用了 luajit ，却担心稳定性问题，把 jit 功能关闭了。
还有 luaclang 这类项目，未必是稀罕 luajit 的性能，更多的是贪图用 ffi 写 binding 的便捷才启用 luajit 的。
5 月 16 日 注：由于已经收到足够多的简历，所以招聘提前终止，谢谢大家的热情。
我们公司 简悦 招聘网络游戏服务端开发人员一名（截至到 2013 年 6 月 1 日）。
基本要求：有至少原创 1000 行以上 Lua 语言编程经验，一万行 C/C++ 语言编程经验。有网络服务开发经验：可以独立解决问题（包括但不限于设计合理的通讯协议，评估其效率及安全性）。
有游戏行业从业经验两年以上可以加分。
有兴趣且满足基本要求的同学，可以 email 和我联系获得更详细的信息。
前几天, Lua 5.2.2 发布了, 主要是修复了 4 个 Lua 5.2.1 中已知的 bug . 其中包括前段时间一个同学和我在 email 交流中讨论的一个问题.
我把 Lua 5.2.2 更新到公司项目的主干上，同时需要对我的那本 《Lua 源码欣赏》做一些更新，需要把这次的代码更改同步到书里去。这个工作很繁琐，但有它的价值。比如我发现了 Lua 5.2.2 比 5.2.1 的更改远不只官方宣布了 4 处 bugfix ，还有一些小调整，让 Lua 的源码更规整一些。
阿楠同学因为这段时间一直在维护 UniLua 这个 C# 版的 Lua 项目，我就随便和他通告了一下这次的一些代码变更，方便他同步到 UniLua 项目中去。
讨论之中，他提到 luaD_precall 函数的实现有些诡异之处，没有看明白。我顺着他指出的位置又仔细阅读了一下，果然发现这里存在一个隐藏很深的 Bug 。
我们游戏客户端使用了 Unity3D , 我们不打算给它写 C 插件, 所有的开发都在 mono 中进行的。
由于某些需求，我们需要在客户端解析一些 Lua 脚本（这些脚本同时供我们的服务器使用）。所以，就有了阿楠同学开发的 UniLua 。
这个世界上已经有了很多的 .net 版的 Lua 实现，但是都不完整。它们大多是基于 Lua 5.1 甚至更老的版本的。还有一些只能解析 Lua 的字节码（这样很容易实现），而不能让 Lua 源代码直接工作起来。这使得在 Lua 中很常见的 meta 编程变得不可用了。
我上次通读 Lua 的源代码时，Lua 还在 5.1 。当然 Lua 5.0 我也读过，4.0 和 3.2 则读的不多。
最近有一点空闲，想续写我那本 Lua 源码欣赏。按我心里的计划，还有大约 6 章。虚拟机、字节码持久化、C API 、解释器、GC、库函数。
新添了一章关于虚拟机的，所以重新读了一遍相关源码。发现 Lua 5.2 比上一版修改了不少，几乎每个位置都有修订。
自己读代码和写出来给人看又是不同，真的逐行推敲的话，之前的理解也是经不起琢磨的。为什么要写这一行；为什么这一行在这个位置，而不是在后面；为什么要这么实现，而不是那样实现……
一边写，一边发现对别处的引用会引发新的疑问，继而需要对之前已完成的章节做一些修补。
上一次发布 pdf 时，采用的是日后纸质书的版式。留白太多对于电子阅读其实是很浪费的，读代码尤其不好。所以这次重新排了一下。
这次主要是增加了关于 VM 的新章节。
有兴趣的同学可以下载：《Lua 源码欣赏》。但我不建议现在开始阅读，尤其是对不仅仅想随便翻翻的同学。因为我经常修改它，今天看到的版本，可能写完后已经改了不少了。
btw, 在我写完后，发现最近有另一个同学也在写类似的文章。这里给出一个链接，有兴趣的同学可以看看。
如何绑定 C/C++ 对象到 Lua 里？通常是创建一个 userdata ，存放 C/C++ 对象指针，然后给 userdata 添加元表，用 index 元方法映射 C/C++ 中的对象方法。
也有另一个手段，直接用 lightuserdata 保存 C/C++ 对象指针放到 Lua 中，在 Lua 中创建一个 table 附加元表来来包装这个指针，效果是类似的。区别在于对象生命期的管理方式有所不同。就这个问题，几年前我写过一篇 blog 。
绑定 C/C++ 对象到 Lua 里的设计难点往往在这个正确的生命期管理上。因为 C/C++ 没有 GC 系统，依赖手工管理资源；而 Lua 则是利用 GC 做自动回收。这两者的差异容易导致在 Lua 中的对象对应的 C/C++ 对象已经销毁而 Lua 层不自知，或 Lua 层中已无对象之引用，而 C/C++ 层中却未能及时回收资源而造成内存泄露。
理清这个问题，首先你要确定，你打算以 Lua 为主干来维护对象的生命期，还是以 C/C++ 层为主干 Lua 部分只是做一些对这些对象的行为控制。
我个人主张围绕 Lua 来开发，C/C++ 只是写一些性能相关的库供 Lua 调用，即框架层在 Lua 中。这样，C/C++ 层只提供对象的创建和销毁函数，不要用 C 指针做对象的相互引用。Lua 中对象被回收时，销毁对应的 C 对象即可。
但是，也有相当多的项目做不到这点。Lua 是在后期引入的，之前 C/C++ 框架层中已做好了相当之复杂的对象管理。或者构架师不希望把脚本层过多的侵入引擎的设计。
那么，下面给出另一个方案。
我们将包装进 Lua 的 C 对象称为 script object ，那么只需要提供三个函数即可。
因为内存限制问题, 我们暂时放弃了 luajit 。这两天，我想另辟蹊径找到别的方法去加速 lua 程序的运行。
所以我这两天做了这么一个玩具，试一下是否可行。
luacc 是类似 cython 的东西，它允许你在 Lua 代码中直接写 C 代码。由于是用 tcc 运行时编译运行的，所以你可以获得和 C 一样的效率。（同样，C 语言引入的问题也同样要考虑）
之所以我称之为玩具，是因为它现在还不支持复杂的数据结构。你只能把单层的，以 string 为 key 的 lua table 映射到 C 代码中（表现为一个 user type ，其实是一个 C struct ）。目前还不能用数组做数据交互。
它可以利用一个内建类型 object 来持有传递 lua 的对象，但不能操作它。
有兴趣做进一步完善的同学，可以去 github 自取。
昨天我们发现每日构建的服务器突然在一个晚上内存暴增了 8 G ，显然是发生了内存泄露。
之前，我们在 skynet 里留下了许多调试协议，使我们很快的确定了发生泄露的服务：在一张地图的 lua State 中。可以确定是地图的 lua 实现中，有些 lua 对象在不断的生成。生成速度不快，但确实没有人解开引用，导致内存持续增长。
曾经有很多人做过 Lua 的内存分析工具，但是我懒的去搜了，花了半天时间自己写了一个。（已经开源在 github 上）
原理是这样的：
我们的系统的应用场合比较特殊，在同一个进程内存在数千个 lua_State 。
Lua 的虚拟机占用的内存已经足够小了，但还是抗不住数量多啊。所以我希望有版本节约一些内存。
最想做的一件事情是把不同 lua_State 中相同的函数字节码合并起来共用一块内存。要做到这一点并不复杂。而且可以提高一些内存访问的效率。（因为大部分 lua 程序在并行执行相同的逻辑）
首先我们需要准备一个用来共享数据块的模块，它必须是线程安全的。因为既然分到了不同的 lua_State 就是想利用并发的优势。针对这个特定需求定制这样一个模块可以做到 lock-free 。
正如上一篇笔记 记载的，我们第 2 里程碑按计划在 9 月 30 日完成，但因为赶进度，有许多 bug 。性能方面也有很大问题，大家都认为需要重构许多模块。所以，在最后几天修补 bug 时，许多补丁是临时对付的（因为整个模块都需要重写了）。为此，我们留下了一个月专门重构代码、修改 bug 、并对最后的结果再做一次评测。
这项工作，终于如期完成了。
半个多月前在白板上留下的工作计划还没擦掉。我列出了 12 点需要改进或重写的地方，考虑到内容较多，又去掉了 3 项。在大家的通力合作下，完成的很顺利。
之前我曾经提到 ，我们的老系统处理 80 人同一战场混战就让服务器支撑不住了。当时我们的服务器 CPU 达到了 790% 。虽然我们的服务器硬件比较老，配置的是两块 Intel Xeon E5310 @ 1.60GHz ，更新硬件可以有所改善。但这个结果绝对是不能满意的。从那个时候起，我从重写最底层框架开始一步步起着手优化。
昨天的测试结果基本让人满意，在同一台机器上，200 个机器人的混战 CPU 占用率平均仅 130% 左右，而机器人 client 边数据包延迟只有 1 秒，完全可以实用。这离我们的设计目标 （ 500 人同战场流畅战斗）还有一些距离，但考虑到今年新配置两块 Intel Xeon E5-2620 @ 2.00GHz 的话，按其性能指标，应当再有至少一倍的性能提升。
ps. 参考这份报告 ，我们计划采购的 [Dual CPU] Intel Xeon E5-2620 @ 2.00GHz Benchmark 16707 分，而目前使用的 [Dual CPU] Intel Xeon E5310 @ 1.60GHz 仅 4160 分。即使仅考虑单线程分数，也在两倍以上。
我们的项目是用 Lua 5.2 标准来写的, 最近想迁移到 LuaJIT 2.0 中。其中碰到的最大障碍是，LuaJIT 2.0 不支持 Lua 5.2 中的 _ENV 特性。而且，看起来将来也不会支持了。
在邮件列表中，LuaJIT 的作者 Mike 看起来很不喜欢这个新特性。
可是我真的需要它，所以只好自己阅读 luajit 的源代码，给它打了个 patch 支持这个特性。
patch (基于 luajit 2.0 的 beta 11) 如下：
最近想试一下, Lua JIT 2.0 能给我们的系统带来多大的提升。但可惜的是，我们一开始就在用 Lua 5.2 来构建系统，而 Lua JIT 2.0 只支持 Lua 5.1 的 API ，在可以看到的时间里，恐怕也不太会去支持 5.2 了。
所以，我只能想办法反向支持 Lua 5.1 。
语法层面最重大的改变是 Lua 5.2 取消了环境表这个概念，转而提供 _ENV 这个语法糖。
许多小细节是 C API 上的变化。这使得按 Lua 5.2 标准写的 C 库，无法在 Lua 5.1 环境下编译。我打算用 Lua 5.1 的 API 来模拟出来。
最近工作展开后， 我们一共有 10 名程序员在目前的项目上工作。我暂时没有和其他人有依赖关系的工作，最近一周在改进以前做的一些东西，在不修改接口的前提下，争取提供更高的性能，以及完成一些之前没完成的功能，为以后的扩展做准备。
最近值得一提的东西是：关于我们的共享储存的数据结构。
最早在设计的时候，是按多进程共享的需求来设计的。希望不同的进程可以利用共享内存来共享一组结构化数据。所以实现了这么一个东西 。这个东西实现的难点在于：一、共享内存不一定在不同进程间有相同的地址，所以不能在结构中用指针保持引用关系；二、不希望有太复杂的锁来保证并发读写的安全性。
后来，我们采用了 Erlang 做底层的框架。在同一台机器上，只有一个系统进程。所以，这个东西可以不必实现的这么复杂。我抽了三天实现，重新实现了一个。这次不考虑跨进程的问题，只在同一进程的不同线程中，让独立的 Lua State 可以访问同一份结构化数据。至于结构化数据支持到怎样的数据类型，我认为和 Lua 原有的 table 类型大致一致就可以了。
最后，就完成了这么一个东西。我认为到目前这个阶段，这个模块还是比较独立的，适合开源分享。以后的工作可能会和我们具体项目的模块整合在一起，还需要做一些修改，就不太适合公开了。有兴趣的同学可以在我的 github 上看到代码。https://github.com/cloudwu/lua-stable 。
问题是早就提出了的。在 开发笔记 18 中，就写到一个需求：一个玩家数据的写入者，可以批量修改他的属性。但是，同时可能有其他线程在读这个玩家的数据（通过共享内存）。这可能造成，读方得到了不完整的数据。
我们可以不在乎读方得到某个时间的旧数据，但不可以读到一份不完整的版本。就是说，对玩家数据的修改，需要成组的修改，每组修改必须是原子的。
起先，我想用读写锁来解决这个问题。方案想好了，一直没有实现。只是把读写锁的基本功能实现了。
这几天这个问题被重提出来。因为，前段我们都采用了鸵鸟政策，当问题不存在（事实上我们也没有发现实际中出现可观测到的问题）。
反正探讨了好几个解决方案，一开始都是围绕怎么加锁，锁的粒度有多大来展开的。甚至，我们把其中的一种方案都实现出来了，并写了压力测试程序测试。不过，这些方案都不太令人满意。大家担心锁的开销，以及逻辑代码编写者所需求关心的问题太多，导致有死锁的可能性。
昨天差一点决定用一个地图锁来解决这个问题，就是用牺牲同一个地图进程上，玩家间并行的可能性为代价的。这个方案也不无不可。但昨晚躺在床上一直睡不安稳。因为这样做，就失去了一开始我期望用并行方案来设计游戏服务器的初衷。如果这样，还不如全部退化到单地图单进程来编写程序。那么一定有方法是可以避开锁以及避免让写逻辑的程序员去关心数据共享的读写冲突问题的。
Lua 5.2.1 正式发布有段时间了。虽然相对于 5.2.0 只是一个小版本的提升，但也是有些东西可以拿出来讲讲的。
比如，在这次小版本更新中，字符串类型被分为了长字符串和短字符串两类。长字符串（大于 40 字节的字符串），不再做内部化处理了。
一开始我以为这是为了性能的一处小改进，可以在字符串处理比较多的场合，少做一些 hash 计算和 hash 表插入。后来查了一下邮件列表发现，其实是为了安全性，防止别人做 hash dos 攻击。一起改变的是字符串的 hash 过程使用了一个随机种子。默认设定和时间有关。值得注意的是，这处改变可能会使得嵌入 lua 的程序每次运行的内存状态不一致，有可能给调试带来一定的麻烦。
我们的服务器框架提供了一个 C 接口, 在 RPC 调用时, 回调一个事先注册的函数.
C 中标准的回调函数的接口设计, 标准方法是设置一个 C 函数指针加一个 void * 类型的数据指针.
由于我们的游戏逻辑使用 Lua 来实现, 所以这里只需要实现一个 C 函数去调 Lua 机里的函数, 而对应的 void * 自然就是 lua_State * 。
今天，同事在实现服务的热更新功能。发现多次热更新 lua 写的服务会导致一处 core dump ，一直没有找到原因。通过阅读代码，我仔细思考后，确定了 bug 所在。
Lua 5.2 最重大的改进，莫过于 "yieldable pcall and metamethods" 。这需要克服一个难题：如何在 C 函数调用中，正确的 yield 回 resume 调用的位置。
resume 的发起总是通过一次 lua_resume 的调用，在 Lua 5.1 以前，yield 的调用必定结束于一次 lua_yield 调用，而调用它的 C 函数必须立刻返回。中间不能有任何 C 函数执行到中途的状态。这样，Lua VM 才能正常工作。
(C)lua_resume -> Lua functions -> coroutine.yield -> (C)lua_yield -> (C) return
在这个流程中，无论 Lua functions 有多少层，都被 lua state 中的 lua stack 管理。所以当最后 C return 返回到最初 resume 点 ，都不存在什么问题，可以让下一次 resume 正确继续。也就是说，在 yield 时，lua stack 上可以有没有执行完的 lua 函数，但不可以有没有执行完的 C 函数。
如果我们写了这么一个 C 扩展，在 C function 里回调了传入的一个 Lua 函数。情况就变得不一样了。
(C)lua_resume -> Lua function -> C function -> (C) lua_call -> Lua function -> coroutine.yield -> (C)lua_yield
C 通过 lua_call 调用的 Lua 函数中再调用 coroutine.yield 会导致在 yield 之后，再次 resume 时，不再可能从 lua_call 的下一行继续运行。lua 在遇到这种情况时，会抛出一个异常 "attempt to yield across metamethod/C-call boundary" 。
在 5.2 之前，有人试图解决这个问题，去掉 coroutine 的这些限制。比如 Coco 这个项目。它用操作系统的协程来解决这个问题 (例如，在 Windows 上使用 Fiber )。即给每个 lua coroutine 真的附在一个 C 协程上，独立一个 C 堆栈。
这样的方案开销较大，且依赖平台特性。到了 Lua 5.2 中，则换了一个更彻底的方案解决这个问题。
在做策划表格解析的时候，我们希望可以在表格里直接填写一些脚本代码。我们的脚本语言使用的 Lua ，所以，直接填写 Lua 代码最为简单。但是，策划同学强烈需要在脚本中直接使用中文。而 Lua 原生并不支持使用中文作为变量名。一开始我们使用了一些变通的方案：比如建立一个字典，把中文词通过程序替换成相应的拼音。倒也能工作。
昨天在午饭途中的电梯里，我想到了另一个方案，用了一个下午实现出来验证可用。
修改 Lua 的语法解析代码，让其支持汉字并非难事。但我不太想通过给 Lua 打补丁，修改 Lua 语言的方式来做这件事情。即，我不想因为这个项目为 Lua 创造一门方言。但是，我们却可以把策划表格中填写的代码当成一种 DSL ，正如之前我实现的公式解析 那样。把这部分用 Lua 的方言来实现，把修改的影响减少到最小，而不蔓延到整个系统的实现语言中去，或许是个更好的方法。
因为 Lua 是否支持中文变量名，只是一个语法解析层面的问题。到了虚拟机解析 bytecode 层面就不存在了。即，我们修改 Lua 的实现，让它支持中文变量名，它解析源代码生成的 bytecode ，是完全可以直接在未修改过的 Lua 环境中运行的，甚至连调试信息都完全兼容。
最近几天优化了一下 pbc 。
这是一个大改动，所以写 blog 记录一下。
首先，我为 rmessage 定制了一个 heap alloc ，在使用 rmessage 解包的时候不再调用系统的 malloc 。而是从一个连续内存 heap 上取用内存。这样在删除 rmessage 对象时也会更快。因为只需要把 heap 回收即可。
当然这样会导致 rmessage 解包时用到的内存增加。对于内存紧张，性能关键部分，我还是推荐 pattern 模式。虽然比较难用，但可以保证时间和空间性能。
另外，我增加了 upb 的 Event-based parsing 模式，见新增接口 pbc_decode 。
不过我认为这个 api 不适合直接在 C 里调用，但是用来做动态语言的 binding 不错。现在 lua binding 中的 decode 就改用这个实现了。这样每次解包就把所有项都解出来，而不用附着一个 userdata 。回避了手动调用 close_decoder 的问题。
btw, 根据一个同学使用的反馈，他们大多不主动调用 close_decoder ，而依赖 gc 回收 decode 过程中产生的 C 对象。但是这些 C 对象申请的内存不会通知 lua ，所以 lua 的 gc 触发条件不会及时触发。这使得 pbc 的 lua binding 可能占用大量内存。我这次的修改主要针对这个问题。
虽然今天发了 twitter ，以及向 lua mailling list 里投递了消息，不过想想还是写一篇 blog 记录一下。
Lua 只支持一种 number ，默认是 double 类型。虽然你可以通过修改 luaconf.h 里的定义，把 lua number 改成 int64 。但是为了 int64 类型而放弃浮点数，恐怕不是大多数人想要的。
int64 通常用在 uuid 上，也就是说不需要对其数学运算，只需要可以比较就好了。我以前最喜欢的做法是用 8 bytes 长的 string 来表示一个 int64 。这样，即可以做唯一的 key 用，又不用做复杂的扩展。
在 pbc 的 lua binding 库 中，对 fixed64 类型，我就是这样处理的。
我们用 lua 做主要的项目开发语言，一直有同学希望可以在 IDE 里单步跟踪调试 lua 代码。我总觉得这个坏习惯是被 Windows 带坏的。当然，很多年前，我也尝试过编写一个图形界面的 debugger 。后来这玩意半途而废了。因为我觉得没啥实用价值，需要这样去调试 lua 程序的程序员反正也写不好 lua 程序。宁可不要这种工具让 lua 程序员的代码质量能提高一点。
后来过了两年，还在网易时，又有同学要求有一个方便点的调试器。我又写过一个远程调试器，gdb like 的界面，用 C/S 方式调试，并用 GTK 配了一个 GUI 的 client 。主要就是远程设置断点，观察变量等。有兴趣的同学可以看这一篇。
这套东西不多提了。今天又有人老话重提。我觉得吧，与其做一个交互式的调试器，不如做一个 trace log 简单实用。毕竟在生产环境，不是有那么多机会让你中断下服务单步调试的。
今天花了将近 3 个小时帮同事看一个崩在 lua VM 中的 bug 结果打乱了进度，没有在年前把预想的东西做完。其实说起来这不是个大问题，以前也碰到过。我检讨自己没有在看到出错时的调用栈时去看一眼 lua 相关的代码。如果是那样，因为以前遇到过同样的问题，所以就可以条件反射出问题原因，而不用荒废宝贵了数小时时间了。
唉，这下整合的进度没接上，过年不能自己一个人接着做下面的活了。
下面记录一下这个 bug ，提醒自己第三次遇到时不用再花时间找问题：
lua 5.2 正式发布了，对于 lua 语言本身的修改，重中之重就是对 environment 这个概念的修改。
可以说， 5.1 以前的 environment 已经没有了。environment 对于制造一个安全的沙盒（或是实现 DSL）是一个很重要的语言特性，我以前很喜欢使用，但也很容易用错。这次的修改我认为是一个谨慎的决定，并使得 lua 语言更为精简和严谨了。
我这样理解 5.2 中的 environment 。本质上，lua 取消了原有意义上的 environment 。所以我们可以看到 C Function 不再有环境了。function 、在 lua 中称为 closure ，仅仅只是函数体和 upvalue 的联合体。这简化了 lua 语言本身。全局变量实际上只是一个语法糖，编译时再前面加上了 _ENV. 的前缀。这样，从 load 开始，第一个 chunk 就被加上了 _ENV 这个 upvalue ，然后依次传递下去。
这个设计基本可以取代以前使用 getfenv/setfenv 改变函数环境的方法。但是又不完全等价。总体来说，增加了一些限制，但不太容易写出 bug 的代码了。
比如说，现在想给返回一个独立环境的函数，可以这样写：
前几天写的 pbc 初衷就是想可以方便的 binding 到动态语言中去用的。所以今天花了整整一天自己写了个简单的 lua binding 库，就是很自然的工作了。
写完了之后，我很好奇性能怎样，就写了一个非常简单的测试程序测了一下。当然这个测试不说明很多问题，因为测试用的数据实在是太简单了，等明天有空再弄个复杂点的来跑一下吧。我很奇怪，为什么 google 官方的 C++ 版性能这么差。
我的 lua 测试代码大约是这样的：
local protobuf = require "protobuf"
addr = io.open("../../build/addressbook.pb","rb")
buffer = addr:read "*a"
addr:close()
protobuf.register(buffer)
for i=1,1000000 do
local person = {
name = "Alice",
id = 123,
}
local buffer = protobuf.encode("tutorial.Person", person)
local t = protobuf.decode("tutorial.Person", buffer)
end
100 万次的编码和解码在我目前的机器上，耗时 3.8s 。
几个月以前，在我在 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 可以使 lua 代码直接使用 C 的数据结构，在实际运用中还可以减少内存的使用。
废话不多说，我的代码放在了 github 上 ，有兴趣的同学可自取。
这个娱乐项目命名为 Ameba ，暗示每个代码单位都足够的小，功能简单。它们必须通过很少的 send/recv 和外界通讯。目前，通讯的数据类型仅限于 number boolean 和 string 。
Lua 5.2 的开发进度可以回溯到 2010 年 1 月。漫长的流程到今天已经快两年过去，终于等到了 beta 版。我十分期待它可以在 2011 年内正式发布。在这几经折腾的两年里，许多新特性企图挤进 5.2 版，又最终被否决。
当我们审视改进列表，似乎看不到太多耳目一新的东西。但如果仔细阅读一下源代码，就会发现，大部分地方都重新实现过了，以配合这些表面上看起来不大的修改。如果你对 Lua 有足够理解，会发现，这次最激动人心的改进是 "yieldable pcall and metamethods" 。官方也把之列为 Main changes 第一条。语言上的重大新特性 goto 却被列在末尾。
当然，这只是我粗浅的理解而已。没有经过实践使用 5.2 一段时间，下这样的论断有点太草率。不过我还是想谈谈，这点改进可以给我们的开发带来什么。
coroutine 的 yield 现在几乎可以在任何地方使用了。我用了几乎，是因为它依然有一些限制。这些限制不大容易说的很清楚，为了理解其限制，我花了一整天实现阅读 lua 5.2 beta 版的源代码。这个话题下次有机会我再另写一篇 blog 总结一下。今天只谈应用。
最近 Lua 社区非常活跃。6 月 22 日发布了 Lua 5.2.0 (beta-rc2) 。今天(6 月 24 日) 发布了 LuaJIT-2.0.0-beta8 。
虽然 luajit 和 lua 5.2 还有点小矛盾，luajit 没有完全支持 lua 5.2 的迹象。不过，这些对 Lua 社区都是好消息啦。可能对于 lua 用户会有点小纠结，到底是追随官方的 5.2 版呢，还是去用性能更好的 luajit2 。我比较在意性能，暂时先投靠 luajit 了。反正和 5.2 区别也不大。更重要的是，luajit2 提供的 ffi 库相当之好用，极大的减少了我们写 C 库的 lua binding 的负担。从某种角度可以看到另一个问题，为基础设施模块设计出良好的 C 接口（而不是 C++ 的）是多么的重要。
zeromq 是用 C++ 实现的，但它提供的是简洁纯粹的 C 接口。这让它相当利于 binding 到其它语言中使用。之前，已经有了成熟的 lua-zmq 可供使用。它分别实现了 ffi 和不带 ffi 的版本。不过也正因为此，封装层包裹的很淡疼。如果只支持 ffi 版本的话，其实这个工作可以做的非常简洁。
出于实践 luajit ffi 库的目的，也为了让这部分代码看起来清爽一点。我花了半个下午自己封装了一下 zeromq 。所用时间比在 windows 下配置安装那个现成的 lua-zmq 所用时间看起来更少（不需要装 msys ，cmake 等等淡疼的玩意）。谁再下面留言说不要重复造轮子了，我也不打算跟它急了。吵架的时间都比写代码时间长。我们从来不会把写一遍 hello world 看成重新制造轮子不是么？使用 ffi 去 binding C 库实在是太容易了，不比写 hello world 更复杂。
前几天分析了 lua gc 的实现细节。这里先汇总一下：
btw, 阅读 lua 的代码是段很有趣的经历。但如果是重头读 lua 的源码，建议从简单的部分读起。gc 恰巧是最难的一段。LuaJIT 的作者 Mike 在这方面很有发言权，他在回答 Which OSS codebases out there are so well designed that you would consider them 'must reads'? 这个问题时，列过一张推荐阅读次序表。我的观点一致，Lua 是少有的设计优秀，C 程序员必读的代码。
从小处说，如果想进一步改进，那是必须仔细研读的（但这绝对不是主要原因）。Lua 的 GC 实现的已经相当不错了，想找出实现中的问题，改进算法，可能很难。如果有多核处理器，那么把 GC 放到一个独立线程里去做倒是可以考虑的。
如果没有前面的研读，恐怕只能用一把大锁来安全处理多线程的 GC 了。lua 的代码为多线程安全预留了 lua_lock 和 lua_unlock 两个 api 。默认是用宏定义出来关闭的，必要的时候可以改写它们。所有的对外 api 都加入了 lock 的调用。
但是，用它来实现多线程的 gc 是完全没有意义的。GC 部分永远不能并行处理。这个东西只是为了多线程访问同一个 lua state 提供了安全保障而已。
下面我们看看能做点什么。
今天来说说 write barrier 。
在 GC 的扫描过程中，由于分步执行，难免会出现少描了一半时，那些已经被置黑的对象又被修改，需要重新标记的情况。这就需要在改写对象时，建立 write barrier 。在扫描过程中触发 write barrier 的操作影响的对象被正确染色，或是把需要再染色的对象记录下来，留到 mark 的最后阶段 atomic 完成。
和 barrier 相关的 API 有四个，定义在 lgc.h 86 行：
今天来看一下 mark 过程是怎样实现的。
所有的 GC 流程，都从 singlestep 函数开始。singlestep 就是一个最简单的状态机。GC 状态简单的从一个状态切换到下一个状态，循环不止。状态标识放在 global state 的 gcstate 域中。这一点前面谈过。
开始的两个状态和 mark 过程有关。
初始的 GCSpause 状态下，执行 markroot 函数。我们来看一下 markroot 的代码。见 lgc.c 的 501 行。
有了前几天的基础，我们可以从顶向下来读 lua gc 部分的代码了。
我们知道，lua 对外的 API 中，一切个 gc 打交道的都通过 lua_gc 。C 语言构建系统时，一般不讲设计模式。但模式还是存在的。若要按《设计模式》中的分类，这应该归于 Facade 模式。代码在 lapi.c 的 895 行：
早期的 Lua GC 采用的是 stop the world 的实现。一旦发生 gc 就需要等待整个 gc 流程走完。如果你用 lua 处理较少量数据，或是数据增删不频繁，这样做不是问题。但当处理的数据量变大时，对于实时性要求较高的应用，比如网络游戏服务器，这个代价则是不可忽略的。lua 本身是个很精简的系统，但不代表处理的数据量也一定很小。
从 Lua 5.1 开始，GC 的实现改为分步的。虽然依旧是 stop the world ，但是，每个步骤都可以分阶段执行。这样，每次停顿的时间较小。随之，这部分的代码也相对复杂了。分步执行最关键的问题是需要解决在 GC 的步骤之间，如果数据关联的状态发生了变化，如果保证 GC 的正确性。GC 的分步执行相对于一次执行完，总的时间开销的差别并不是零代价的。只是在实现上，要尽量让额外增加的代价较小。
先来看 GC 流程的划分。
最近发现在大数据量的 lua 环境中，GC 占据了很多的 CPU 。差不多是整个 CPU 时间的 20% 左右。希望着手改进。这样，必须先对 lua 的 gc 算法极其实现有一个详尽的理解。我之前读过 lua 的源代码，由于 lua 源码版本变迁，这个工作还需要再做一次。这次我重新阅读了 lua 5.1.4 的源代码。从今天起，做一个笔记，详细分析一下 lua 的 gc 是如何实现的。阅读代码整整花掉了我一天时间。但写出来恐怕比阅读时间更长。我会分几天写在 blog 上。
Lua 采用一个简单的标记清除算法的 GC 系统。
在 Lua 中，一共只有 9 种数据类型，分别为 nil 、boolean 、lightuserdata 、number 、string 、 table 、 function 、 userdata 和 thread 。其中，只有 string table function thread 四种在 vm 中以引用方式共享，是需要被 GC 管理回收的对象。其它类型都以值形式存在。
但在 Lua 的实现中，还有两种类型的对象需要被 GC 管理。分别是 proto （可以看作未绑定 upvalue 的函数）， upvalue （多个 upvalue 会引用同一个值）。
Lua 是以 union + type 的形式保存值。具体定义可见 lobject.h 的 56 - 75 行：
需求来自于，我希望可以对 lua 虚拟机中的内容做持久化，却又不希望 stop the world 。这需要利用 os 的功能，对内存做一个快照。简单的 fork 就可以达到快照的要求，但是 fork 会快照整个进程的地址空间，这不是我想要的。
这两天和几位同学讨论了各种方案，比如 memcpy ，比如 fork+exec 传递 shm_open 的 fd ， fork 后 munmap 不用的区域等等。最后我认为如下方案相对更满意一些。我并没有实现出来， 写 blog 只是做个记录。
前段时间在玩 Go ，非常喜欢 goroutine 的编程模型。采用 chan 进行 thread 间的通讯写起来很舒适。今天花了一个下午，为 lua 写了一个简单的库，模拟这种编程方式。暂且把这个东西叫作 lua cothread 。它基于 lua 的 coroutine ，只是写了个简单的调度器。
这个库有如下几个 api ：
又仔细推敲了两天，把 lua 版的 protobuf 库完善了一下。主要是做了两个工作：
protobuf 本身的格式，google 是自描述的。定义为 google.protobuf.descriptor 。我先自己实现的 parser 图方便，用了自己的中间交换格式。为了日后更通用，稍微修改了一下，可以生成于官方相同的结构。解析的性能稍有下降，不过应该兼容性更好。
一开始实现的 api 虽然性能非常好。（经简单测试，是 python 库的 30~40 倍，和 C++ 库性能相当）但若消息格式复杂，实现起来稍有麻烦。所以我做了点小封装。即为每个消息生成一对函数，可以用来打包和解包完整的消息，映射到 lua 的 table 结构上。lua 生成代码供自己调用的技巧在 lua 社区广泛使用。比如 kepler 项目。这使得 lua 可以用很短的代码行数完成很复杂的工作，不失性能。我这个封装层只有 100 行代码左右，一大半代码是为了解决消息展开时有递归定义的情况，否则更简短。（message 中有一些 field 的类型是自己，这是一种不多见的用法，但 protobuf 似乎并没有拒绝这种用法）
Google 的 Jeff Dean 同学说，设计分布式系统一定要有 Protocol Description Language。
Google Proto Buffers 的意义在于，定义了一个不错的 PDL 。protobuffers 的实现反而不那么重要了。
这几天我一直在倒腾 lua 下的 proto buffers 的支持。一直在思考，怎样的接口才是最适合 lua 使用的。
大多数语言下的 proto buffers 实现，都是将编码的数据块展开成本地语言的数据结构。对于 C/C++ ，这是最高效的形式。但对于动态语言，那就未必了。虽然 google 为 python 做的 proto buffers 的官方实现也是如此，但我依然想考虑一下，是否有更高效的方式来做这件事。
《Masterminds of Programming: Conversations with the Creators of Major Programming Languages》是本相当不错的书。博文翻译出版了这本书，中文名叫做《编程之魂》。
书是好书，可惜翻译这本书需要对各种语言的深入研究，看起来译者有点力不从心。出版社打算重新做这本书。受编辑所托，我校对了其中第七章：有关 Lua 的一段。原文读下来拍案叫好。可惜译文许多地方看起来有些词不达意。许多在口语化交流中提到的术语被忽略了做了错误的翻译。有些部分应该是对 lua 理解不够而没能表达清楚。
仔细校对了两段后，我干脆放弃原译本，自己动手翻译了一份（保留了不到 1/4 原来的译文）。虽然个人能力有限，但也算是每句话自己都看明白了再译的。虽说有些地方没有直译，但也算没有夹带私货。
这里贴出一段，希望大家阅读愉快。
今天和倩女幽魂的同事讨论一个问题：他们的游戏 client 中，有大量策划填写的表格直接导入 lua state 中的大量数据。大约有 100M 以上。这样，如果玩家在一台机器上启动多个 client ，就会占用大量的内存。
而这些数据，一旦加载进 lua ，就不会再修改，且每个 client 中数据都是一致的，这是一种浪费。
问题是：如何利用进程间的数据共享，在多开 client 时节省这些空间。（同时也可以加快开第二个 client 的启动速度）
[ANN] Lua 5.2.0 (work1) now available ，这个消息有几天了。lua 社区这两天非常热闹，各大牛都现身了。
做 LuaJIT 的牛人 Mike Pall 对 bit 库没有采用他做好的现成方案那可是相当的不客气。
不过，欢呼雀跃的人还是比较多的。每次 lua 升级个小版本，改动都非常大。对成熟项目，不给你伤点筋骨，那就不是 lua 三巨头的风格了。当然，对于时不时重写代码的我，欣赏这种风格 ;) 我喜欢更健康的 lua 语言。
嗯，无论如何，lua 的源代码是非常值得阅读的。
几个月前， Mike Pall 就在 lua 的 mailling list 里叫嚣他的 luajit 2.0 用的新算法将会大幅度提升性能。还记得 Soloist 同学当初就是眉飞色舞的跟我说这个事。所以 luajit 2.0 还真是万众期待啊。至少 lua 社区的人都等着呢。
昨晚，Mike Pall 同学终于放出了 beta 版。那个性能测试结果真是很吓人啊。
ps. 我昨天刚把项目里的几个命令行工具用 lua 改写，并把 srlua 加到了 makefile 框架里。嗯，可以考虑做一个带 jit 的 srlua 。
这个是我将在今年 SD 2.0 大会上进行的议题的演示稿。最近太忙了，国庆期间在家写的草稿。
有兴趣的同学可以看看，没兴趣的请无视。
另外我会作为嘉宾参加 SD 大会的一个所谓算法论坛。还不知道谈些啥呢。
一个 lua 的小技巧
在写 lua debugger 的时候，我需要判断一个字符串的前缀是不是 "@" 。
有三个方案：
我推荐第三种。（注：在此特定运用环境下。因为用于判定 source 的文件名，大多数情况都是 @ 开头。如果结果为非，则性能较低）
第一方案 string.sub 会在生成子串的时候做一次字符串 hash ，感觉效率会略微低一些。
第二方案效率应该是最好，但是需要记住 @ 的 ascii 码 64 。如果前缀是多个字符也不适用。
前两年写过一个 lua 的调试器，blog 上有截图
不过调试器设计的关键不在于界面，在于调试协议。前两年的那个是设计的不完整的。
最近同事强烈要求引擎提供一个强力的调试工具，虽然我个人不太依赖调试去写代码。甚至认为，经过反复调试才正确工作的代码不是好代码。不过周末还是花了点时间重新制作了一个 lua 调试器。
中间发现一些问题，非常让人吐血。列在这里，做个记录。
要写过多少代码才能得到哪怕一点真谛？
多少年过来，我在潜意识的去追求复杂的东西。比如我自幼好玩游戏，从小到大，一直觉得玩过的游戏过于简单（无论是电子游戏还是桌面游戏），始终追寻更复杂规则的游戏，供我沉浸进去。或许是因为，有了更高的理解和控制复杂度的能力，就可以更为轻松的驾御复杂性。
这很好的解释了 2000 年到 2004 年我对 C++ 的痴迷。还有对设计模式的迷恋。
Eric S. Raymond 说：尽量不要去想一种语言或操作系统最多能做多少事情，而是尽量去想这种语言或操作系统最少能做的事情——不是带着假想行动，而是从零开始。禅称为“初心”（beginner's mind）或者叫“虚心”(empty mind) 。
代码写多了，问题见过了，甚至是同一问题解决多了。模式这种东西自在心底，不必拿出来。时时的从零去想，总能重新明白一些道理。
为什么说语言重要也不重要，算法和数据结构重要也不重要。对要解决的问题的领域的理解很重要（即明白真正要做什么）。理解了，我们才可以用面向对象，用模式去套问题；可理解了，我们又不真的需要这些繁杂的抽象。
闲话放一边，今天想谈谈树结构的管理。
第一件事就是没有钩子。不要留一个接口，想着未来的什么时候当问题变化时插入一些代码，因为问题会以你不能预见的方式变化。反正这个成本肯定是浪费了。不要预测，只解决你眼前的问题。by Charles Moore (Forth 之父)
今天也是机缘巧合，莫名其妙的翻出老资料温习 Forth 了。我想是个心结吧。19 年前，我痴迷于 Forth ，只看到了皮毛；13 年前，我进入大学的第一年，在校图书馆借出的第一本书，就是《Forth 语言》，读书笔记写了 20 多页。
只到今天，我才有机会，有能力，去仔细探究 Forth 的深层思想。当然，由于时间有限，几个小时的阅读，也只算是初窥门径。原本是想研究下 Forth 的系统实现，对同事正在设计的 3d 粒子系统，提供一些建议的。
碰巧又读到 Charles Moore 在 99 年的访谈稿 1x Forth ，颇多感慨。题头那段话，我在一周前刚好苦口婆心的对一同事说过，只差几个字而已。
php 中有个 print_r 函数，可以递归打印一张表。很多 php 程序员喜欢用这个去调试程序。
我想，所有写过一定代码量的 lua 程序员都会写一个类似的东西放着备用吧。这两天调试 lua 程序的时候，发现以前做的简陋的 print_r 不够好用。对于复杂的 table 打印出来一大篇很不直观。结果就放下手头的工作，花了整整一个小时，写了下面几十行代码。把 table 输出成树结构。
比如：
a = {}
a.a = {
hello = {
alpha = 1 ,
beta = 2,
},
world = {
foo = "ooxx",
bar = "haha",
root = a,
},
}
a.b = {
test = a.a
}
a.c = a.a.hello
print_r(a)
可以输出成：
+a+hello+alpha [1]
| | +beta [2]
| +world+root {.}
| +bar [haha]
| +foo [ooxx]
+c {.a.hello}
+b+test {.a}
警告：记录以下内容纯粹自娱，请勿轻易用于项目。我个人也不赞同随意使用语法糖去改造语言。
我们知道 C++ 里有函数重载的特性，程序员可以为一个看起来同名的函数做多份实现，让编译器通过调用时的参数类型去指定链接器链接最为匹配的一份实现。对于死忠的 C++ 程序员，这绝对是最必不可少的利器。如果没有它，那些 template 绝对玩不出现在这么多花来，当然也就没那么多机会拿着“充满智慧” 花哨的 template 代码来 YY 自己的智商了。
哦，写 lua 的所谓脚本程序员不要沮丧，其实 lua 中可玩的花样也很多。一样可以写出让同行瞠目结舌的代码来。比如这个函数重载的问题，虽然 lua 不可能做所谓编译期运算（动态生成代码或许勉强算一个），也没有什么静态链接过程。
但 lua 是个有趣的语言，下面看我怎么模拟出一个类似的东西来。
wow 开放了一套用户自定义的插件系统，很多人都认为，这套系统是 wow 成功的因素之一。反观国内乃至韩国的网游，至今没有一款游戏能提供相当自由度的用户自定义插件系统。
最开始，暴雪是想让用户可以由用户甚至第三方自定义操作界面。后来，这套基于 XML 和 lua 的插件系统不仅仅用来做界面了。
从我在网游行业从业这么多年的经验，游戏界面相关的开发也是颇费人力的。甚至于，Client 开发到了维护期，几乎都是在 UI 上堆砌人工。一套自由的插件系统，对于开发商和用户是双赢的。
但是，插件系统也是双面剑。最典型的负面问题就是安全。越是自由，越是给机器人制作开放了自由之门。这里暂且不提这个方面的问题。首先关注一下另一个：尽可能的保护系统中不想被插件系统访问的数据，避免利用插件编写木马。
把同质的东西放入一个容器，然后用迭代器迭代这个容器，把里面的内容逐个取出来处理。这是一个非常常见的需求。但是，这个过程往往也会滋生 bug 。因为，若将容器看成一个对象，那么对其迭代的这个操作很难实现原子性。
非原子性导致了，在迭代过程中，十分有可能对容器本身进行修改。或增加若干元素，或删除若干元素。这些都容易造成迭代过程不正常。
所以，最终我们需要根据需求设计以及实现合理的容器。比如管理消息的消息队列，严格的满足尾进头出，没有删除中间数据的需求，就不会导致 bug 。
那么，如果容器是一个集合怎么办？即，允许向其中增加新的元素，也可以移除某些元素。这种数据结构非常有用。比如向某对象注册若干回调函数，一旦满足条件则依次调用。即设计模式中的 Observer 观察者模式。回调函数就极有可能增加新的观察者或某些老的观察者退出。
把 C 里的对象封装到 lua 中，方便 lua 程序调用，是很常见的一项工作。
里面最大的问题是生命期管理问题。
通常有两种方案：
第一：编写 C 库的时候，完全针对 lua 设计，所有对象都有 lua_newuserdata 分配内存。对象和对象之间的联系可以使用 userdata 的 环境表，把对象间的引用放在里面，使得 lua 的 gc 过程可以正常进行。
第二：给 C 对象简单加一个壳。lua 的 userdata 中仅仅保存 C 对象指针。然后给 userdata 设置 gc 元方法，在被回收时，正确调用 C 对象的销毁函数。
以上两种方案都依赖 lua 的 full userdata ，这里，我想提供第三种方案，仅使用 lightuserdata 完成这项工作。
这第三方案未必比前两种都好。虽然从字面上理解 light userdata 比 full userdata 更廉价，但诚如 pil 中所言，full userdata 也非过于重量。
最终的方案选择还是要结合实际的设计，仔细考量。
周末有同事问我一个问题，说他们猜测在他们系统里 lua 的垃圾回收过程导致了系统开销过大。而其中有些开销是无谓的。
比如在他们的系统中，有大量的结构化数据是只读的，不会和其它数据产生联系。大多为策划设定的游戏逻辑参数。而偏偏这部分数据结构复杂，在 lua 的 gc 过程中会产生大量的遍历。但我们明明知道，这些数据一定不会被回收掉，且不会影响 gc 的结果。那么有什么方法可以优化呢？
Lua 的函数定义是没有参数类型信息的。这些信息在跨语言的模块化设计中非常有价值。因为跨语言的方法调用通常需要做列集(Marshaling) 的操作，缺乏类型信息很难完成这个工作。同样的需求在做 RPC 调用的时候也很重要。
感谢 Lua 简洁的 metatable 的设计，我们可以用一个简单的方法自然的描述出 Lua 函数的调用参数类型，又无损性能。
一开始，我们先回顾一下在 Pil 中推荐的类实现方法。通常我们可以把方法列表（对应于 C++ 中的虚表）放在一个 table 中，然后把这个 table 作为一个 metatable 的 __index 方法，并把 metatable 附加到一个 table 上，就生成了简单的对象。我喜欢这样做：
lua 里其实也颇多奇技淫巧，使用时应三思。
如果你读过 kepler 的代码，就会发现，多次编译这种技巧用的很多，甚至迭代几次使用。即，第一次加载代码时，用一段 lua 程序生成真正需要的源代码，然后再将其编译出来。
由于 lua 的编译速度相当快，而且这种迭代编译的过程仅仅在程序加载的时候进程一次，故而可以带来性能的提高：一些在系统初始化时可以决定的参数（比如从配置文件中读出来的数据）直接编译为常量置入程序中。
云风写了一小段 lua 程序，简化这种迭代编译的过程，算作周末自娱吧。
例如这样一个例子，我们在程序中需要用一个常量，这个常量可能是通过加载配置文件得到。假设允许编译期计算，我们可以这样：
function foo()
for i=1,| config "max" | do
execute(i)
end
end
这个例子里，循环的终值是通过调用 config "max" 得到的，如果每次运行这个程序时都去查询 config 必然影响效率。我们需要在程序加载时，第一次得到 config "max" 的结果即可。
这里，我使用 | 夹在中间 | 表示这段代码应该在加载时运行。
有点像 php 写网页用的模版？呵呵，可以接着往下看。
嗯，首先，此贴不是牢骚帖。
话题从最近私人的一点工作开始。应 dingdang 的建议，我最近在帮 大唐无双 做一些程序上的工作。接手做这件事情，是因为这个内部被我们称作 dt2 的游戏 engine 关系重大。公司有至少四个项目在使用（另外三个暂处于研发期，尚未公布）。
dt2 用了大量的 lua 代码构建系统，但从系统设计上，沿袭了老的大唐的许多代码。原来的大唐是用 C++ 构建的，为了利用上这些代码（虽然我觉得这种复用非常无意义，但是其中原因复杂，就不展开谈了），dt2 engine 的开发人员做了一套非常复杂的中间层，把 lua 和 C++ 几乎无缝的联系在了一起。
读者向海飞给我 email 了一份他翻译的《The Implementation of Lua 5.0》这篇 paper。原文可以在 lua.org 上下载
这篇由 lua 作者们写的 paper 对理解 lua 非常有帮助。有兴趣的朋友在 这里下载译文
译文最后附有译者的 email 大家可以直接向他反馈。
其实我并没有用 lua 亲手写过什么大规模的项目。超过 5 千行代码的项目几乎都是 C 或是 C++ 写的。这几天算是做了点复杂的玩意了。几经修改和删减，最后接近完工的这个东西统计下来不多不少 3000 行（误差在十位数）。其中用 C 编写了基础模块 900 多行（仅仅是 socket api 的封装和 byte 流的编码解码），剩下的都是用 lua 设计并实现的。
好吧，我承认 2000 多行代码也只是一个小东西。不过用 lua 实现的一个 wiki 系统，sputnik 还不到 2000 行呢。lua 有一种特质，用的久了就容易体会到。它和 python ruby 这些更为流行的动态语言是不同的。曾经，我把选择 lua 的理由，肤浅的停留在了更轻便更高效上，虽然这些也很重要，但抓住语言的特质才是更关键的。
很久没写 blog 了，主要是忙。项目排的很紧，一个小项目上线，发现不少问题，所以把多余精力都投进去了。最后人手不够，亲自上场写代码。在不动大体的情况下，最大能力的修改了一些设计，并把能重写的代码重新写过了。
这一周，写了三天半程序（其中通宵了一次）。平均每天写了千多行程序。基本上把原来项目里用的几万行东西替换下来了。重构总是能比老的设计更好，不是么？ :) 不过这事不能老干，个人精力再充沛。故而还是找到称心的合作人比较好，也不能啥都自己做啊。程序员的效率差别可不只十倍二十倍的差别这么少。btw, 前段时间通过这里找到的新同事不错，呵呵。如果有缘，还想再找一个能干的。我相信，聪明人在一起做事可以获得更多快乐。
闲话扯到这里，总结下这两天做项目的一点经验。那就是：当我们需要一个 7*24 小时工作的系统时，实现热更新需要注意的要点。当然，这次我用的 lua 做实现，相信别的动态语言也差不多。只是我对 lua 最为熟悉，可以快速开发。
今天同事在设计引擎的脚本接口时遇到一个问题：需要把 C 对象指针放到 Lua 中，允许 Lua 保存这个指针，并传递给其它模块。
这是给 Lua 写 C 扩展时常见的问题，撇开如何如何将对象的方法导入 Lua 这个更复杂的问题不谈，我主要想说说 C 对象的生命期管理的问题。
一开始的设计是把对象的销毁方法也导入 Lua ，由脚本程序员手工管理。这是很明显的 C 程序员的思路：谁构造谁释放。但在这里是不合适的，不符合带 gc 机制语言的习惯。
我们当然希望脚本更为健壮，不需要考虑对象释放的问题。所以晚上我想了一下，修改了一下这部分的实现。
起因是这样的：
几个同事在棋牌群里聊天，说找不到搭档打桥牌。网上也没啥好地方去，大家都比较讨厌下客户端和注册。我说，不如我做一个免客户端免注册的桥牌网站吧。然后就开始了。
直觉告诉我，ajax 技术可以实现这些。但是我没做过 web 方面的开发，仅有的一些知识只在几年前写过一个 php 留言本。一开始觉得 ajax 这些时髦玩意学一下午，然后一通宵就可以把想要的东西做出来。哪知道，结果不务正业干了半周了，中间还熬了两晚上，到今天都没做完。明天要出差，只好放一放了。
Lua 提供了一个注册表（REGISTRY）让我们的 C 扩展可以安全的把一些运行时数据放进去，而不被 lua 代码碰到。为了让各个 C 扩展库之间可以相安无事的工作，并且对注册表的操作又有较高效率。Lua 大神 Roberto 在神作 Pil 里给出了一个简洁的方案：用 static 变量的地址作为 key 。
静态变量在当前进程中一定拥有惟一的地址，且 lightuserdata 作 key 非常高效。这无疑是一个好方法。
但是，当模块的源码规模变大了以后，我们将代码分散到不同的源文件中。或者几个子模块需要相互协作时。这个方法就有了一定的缺陷。那就是，必须将这个静态变量暴露出来供大家蹂躏；或是写一个内部函数来取得它（其实没有本质区别）。
如果你也碰到这类问题，不妨看看下面的解决方案。
晚上一个小朋友在 gtalk 上问我编程语言专注哪一门好。当然这不是一个简单能回答的问题。尤其对刚上大学的小朋友不太好解释清楚。
不过睡觉前我还是八卦了一下当今世界编程语言的流行程度排名。查了下 TIOBE 的排行榜。首先映入眼帘的加黑的头条：Lua only 0.003% away from top 20 position 。
不得不感叹魔兽世界的影响力啊。（同事语： wow 让阿猫阿狗都开始写 lua 程序了）回想 05 年的时候，Lua 可是排在 70 多位的。
我们在 01 年底为大话西游2 选择一门嵌入式脚本语言的时候，考察了 lua python java javascript ruby 等许多开源动态语言（java 是个例外，而且 java 不开源，但还是可以找到一些 JVM 的开源代码）。最后定下 lua ，其中一个原因就是它不太为人所知。反逆向工程可能可以方便一点，真没想到今天会是这个局面。（当然，那个时候 python 和 ruby 在国内用的人也相当的少）
是金子总会闪光的 :D
在 Windows 下写一些关于窗口的程序时，如果在软件中嵌入 lua ，那么就很有可能遇到一个棘手的问题：如果你需要用 lua 来直接响应一些 Windows 消息，那么如何向 WinProc 传递 lua_State ，也就是那个充斥于 lua 代码中的 L 。
在 Lua 的第 4 版及以前，这个问题并不突出。因为大多数情况下，我们并不需要嵌入多余一个的 Lua 虚拟机。而 L 这个指针，从 Lua 虚拟机被创建出来以后，就不会改变。那么我们只需要把 L 保存在一个全局变量中就可以了。若是你的程序是多线程的，并且每个线程都开有独立的虚拟机，把这个全局变量放到 TLS 中就可以完美的解决问题。当然一些全局变量的排斥者，会想到把 L 放到 Window 对象的 USERDATA 中，这也未尝不是一个体面的方法。
但是，从 Lua 5 开始，因为 coroutine 的引入，即使只打开一个虚拟机，我们也会面对不同 L 的问题。这个问题早在去年就困扰过我，我和同事一起也讨论并研究过这个问题，当时得到了一些解决方法。今天，我重构代码，又想起这个话题，觉得有必要把当初的思考、结论和今天的想法纪录下来。
在 lua 的 maillist 上最近报告了一个 bug 。
看起来问题比较严重，因为稍具规模的 lua 程序都可能因此而出现问题。最近两周，我和我的同事都比较关注这个问题，并对 lua 的源代码做了相关的分析。
Roberto 作为 lua 委员会三巨头之一，在 mail 中已经表示追踪到 bug 的起因，但暂时还找不到合适的解决方案。直觉告诉我，这不会是一个简单的问题。如果容易修正的话，patch 早就有了，而不会只是发一个 bug report 而已。所以我们也并未尝试自己去修补这个 bug ，可以做的可能只有等待。
lua 中，我们可以用 userdata 保存一个 C 结构。当我们为 lua 写扩展时，C 函数中可以利用 lua_touserdata 将 userdata 转换为一个 C 结构指针。
但是，有时候我们却需要把一个指针转换回 lua 中的 userdata 对象。用到它的最常见的地方是封装 GUI ，通常 GUI 的底层是用 C 编码的。当 engine 把鼠标位置或是别的消息拦截到以后，消息会被传递到一个 C 对象中。这个时候，我们需要从 C 对象中得到对应的 lua 对象，并触发事件。
以前版本的 lua 缺省是调用的 crt 的内存分配函数来管理内存的。但是修改也很方便，内部留下了宏专门用来替换。现在的 5.1 版更为方便，可以直接把外部的内存分配器塞到虚拟机里去。
有过 C/C++ 项目经验的人都知道，一个合适的内存分配器可以极大的提高整个项目的运行效率。所以 sgi 的 stl 实现中，还特别利用 free list 技术实现了一个小内存管理器以提高效率。事实证明，对于大多数程序而言，效果是很明显的。VC 自带的 stl 版本没有专门为用户提供一个优秀的内存分配器，便成了许多人诟病的对象。
其实以我自己的观点，VC 的 stl （我用的 VC6 ，没有考察更新版本的情况）还是非常优秀的，一点都不比 sgi 的版本差。至于 allocator 这种东西，成熟的项目应该根据自己的情况来实现。即使提供给我一个足够优秀的也不能保证在我的项目中表现最佳，那么还不如不提供。基础而通用的东西，减无可减的设计才符合我的审美观。sgi 版 stl 里的 allocator 就是可以被减掉的。
好了，不扯远了。今天想谈的是，如何为 lua 定制一个合适的内存分配器。
今天写程序的时候发现一个问题，我为 lua 写了一个叫作 console 的 C 扩展库，可老是加载失败。郁闷了好半天后终于找到问题，那就是 lua 解释器实际找到的是 windows/system32 下的一个同名 dll 文件。原来系统也有一个 console.dll 了。
记得从前没有这个问题的，上网查了下 msdn 终于发现其缘故了。原来 windows xp sp2 以后，动态链接库的缺省搜索次序被修改了。
最近想做一个 visual 版本的 Lua 远程调试器。奋战了两天弄出这样一个玩意出来。如果有精力做完，就可以在 Windows 下远程调试任何地方的 Lua 代码了 :D
如果近期没精力，就开源让别人继续做好了。
Lua 5.1 带了一个 debug 库，把所有的 C API 中的 debug 相关 api 都导出了。作为独立的语言使用的话，这些足够搭建一套方便的调试库。
说到最常用的断点调试法，我们能想到的最直接的方法就是利用 lua debug 库中的 hook ，然后记录一张断点位置表，设置行模式的 hook ，每次进入 hook 都检查是否是断点处，若是就停下来等待交互调试。
这个方法很有效，但是很消耗 cpu 。因为每进入一个新的代码行，都需要回调一个函数。当这个函数本身又是用 lua 写的时候，效率更低。
本文提供另一种思路，换一个方法设置断点，让没有断点时不影响运行效率。
今天方舟组的同事问到我一些 lua 的问题，主要是关于 C 扩展库的。我觉得有些技巧性的东西挺值得跟大家分享一下，那么就写篇 blog 吧。
通常，C 扩展库中 C 代码会有一些数据要放在 lua 状态机中。Lua 提供的方案是放在它的 注册表 中。如文档所言，因为 Lua 的注册表是全局共享的，选择 key 的时候就要千万小心了。整数 key 已经被 reference 系统用掉了，一般我们会采用字符串作 key 。
从 C 中压入字符串的效率不是最高，这是因为外部字符串进入状态机时需要重新 hash 并检查唯一性所致。关于避免直接压入字符串的问题，以前写过一篇 blog 谈过。( btw, 以前那个方法也不是最好的解决方案，不过还是可以作为一个参考的 :)
很容易想到，最方便且能保证唯一性的 key 是一个 light userdata 。这一点，在参考手册以及 Programming in Lua 中都有提到。
前段时间安排同事工作时间翻译了 Lua 的参考手册 。当时的目的是想让翻译的人可以借翻译的机会深入了解这门语言。另外，其他人在查手册的时候也可以轻松一点。
事与愿违，这个中译本陆续经过了几个月的翻译和校对后，可读性依然欠缺。往往我需要去手册里查点东西的时候，都发现还不如直接看英文原版。中文译文读的晦涩倒是次要的，主要是一到关键点上就译的含糊不清，甚至有错误。
这倒符合我的观点，翻译技术资料，首先要求的是对原文的理解，然后是中文的组织水平，最后才是英文水平。
周末，我突然发神经，自己动手译了一下（其实起先只是想看看翻译这个篇幅的文档大约需要多少工时）。花掉两个半天敲了大约一万两千汉字，手都快抽筋了：）把最重要的一部分关于 Lua 语言的译完。
我想我的英文水平是很糟糕的，中文能力也不怎么样，不过满足翻译技术文档的第一要点：对 Lua 本身是很熟悉的。所以这个译本当是能看吧。
很多技术术语我没有按标准译法来译，尽量用一些更通俗但是更繁杂的译法。大部分译词，如果我认为大家普遍能接受，就统一用中文译词，只在第一次出现时括号注明英文原文。例如：事件 (event) 、元方法 (metamethod)。
如果觉得译词不太能被大众接受，大部分地方保留英文，而在第一次出现的地方括号注明我认为合适的中文译法。例如 metatable （元表）、closure（闭包）。
2006年11月19日 凌晨： 手册的第三部分（C API）业已完成 :D
最近写的代码中出了一个奇怪的 bug ，很难调试出来。经过一个晚上的挣扎，终于发现了问题。
第一个问题，在 C 函数中，不能随意的时候 lua_State 中的虚拟机堆栈，如果需要大量使用堆栈，应该先调用 lua_checkstack 。少量使用堆栈，（在 LUA_MINSTACK 20 ）之下时则没有问题。这个问题其实在文档里有写，我看过忘记了 :( 不过我个人还是觉得 lua_checkstack 的语义有点奇怪，从字面上看，这个 api 不应该有副作用。它能增加可用堆栈的大小违背了 checkstack 的词义。
第二个问题，当从 lua 调用 C 函数时，当参数数量不足的时候，并不会填入 nil 作为缺省参数。比如，写了一个 C 函数，接受两个参数。当 lua 中调用这个 C 函数时，如果仅传入一个参数，那么在 C 中 stack 上 index 2 位置的值并不一定是 nil 。这个时候我们应该用 lua_gettop 得到准确的参数个数以做适当的处理，或者直接在进入 C 函数时调用一次 lua_settop(L,2) 强制堆栈扩展到两个。
第三个问题，就是一开始最为迷惑我的问题。在生成 cclosure 的时候，upvalue 不能超过 255 个。而这一点并没在文档中说明，运行时压入超过 255 个 upvalue 也不会报错。知道仔细查看源码才发现其中的秘密。
昨天同事谈起能否给一个从 lua 中调用 Windows API 的简单方案。一开始觉得，如果是一个通用方案，那么至少需要先给出一个类似 windows.h 的原型声明，然后从 lua 来解析这些原型。大约写了几十行程序就实现了。后来又想了一下，似乎可以用一个更简单的方式，绕过原型，更简洁（但不保证安全）的方法来做到。
其间的问题就只有一个，每个 api 的参数都不一样，如何自动生成 C 中匹配的函数指针。似乎 C++ 的 template 是一个正统的解决方案。不过思考过几分钟以后，就被我否决了。实际用到的解决方案比较诡异：
先用 alloca 分配出正确的参数空间，再立刻填充这些参数，接下来以无参数的形式调用 api 。这样做，对于 __stdcall 的函数是没有问题的。好在 api 大多也是这样。
我写了这样一段程序来验证我的想法：
在 pil 中，lua 的作者推荐了一种方案来实现 OO，比较简洁，但是我依然觉得有些繁琐。
这里给出一种更漂亮一点的解决方案：为了贴代码和修改方便，我把它贴在了 wiki 上。
在这个方案中，只定义了一个函数 class(super) ，用这个函数，我们就可以方便的在 lua 中定义类：
base_type=class() -- 定义一个基类 base_type
function base_type:ctor(x) -- 定义 base_type 的构造函数
print("base_type ctor")
self.x=x
end
function base_type:print_x() -- 定义一个成员函数 base_type:print_x
print(self.x)
end
function base_type:hello() -- 定义另一个成员函数 base_type:hello
print("hello base_type")
end
以上是基本的 class 定义的语法，完全兼容 lua 的编程习惯。我增加了一个叫做 ctor 的词，作为构造函数的名字。
这一天等了很久，终于看到了这则消息：
Lua 5.1 (final) is now available at http://www.lua.org/ftp/lua-5.1.tar.gz
Thank you very much for your patience during this long release process. Special thanks to everyone that sent suggestions. They have helped make Lua still better.
Enjoy! We can now focus on 5.2 :-) --lhf
lua 从 5.1 开始终于官方提供统一的 module 实现标准了，这是个值得庆幸的事。今天读了下相关的源码和文档，把这套机制搞清楚了，还是很巧妙的。从简洁这个角度看，要比 python 强 :)
有一点容易被忽略掉(我的同事在用的时候就忽略掉了)，module 指令运行完后，整个环境被压栈，所以前面全局的东西再看不见了。比如定义了一个 test 模块，使用
module("test")
后，下面不再看的见前面的全局环境。如果在这个模块里想调用 print 输出调试信息怎么办呢？一个简单的方法是
local print=print
module("test")
这样 print 是一个 local 变量，下面也是可见的。或者可以用
local _G=_G
module("test")
那么 _G.print 也是可以用的。
当然还有一种巧妙的方式，lua 5.1 提供了一个 package.seeall 可以作为 module 的option 传入
module("test",package.seeall)
这样就 OK 了。至于它们是如何工作的，还是自己读源码会理解的清楚一些。
在读源码时可以发现很多 lua 的技巧，还有一些 undocumented 的东西，比如 newproxy :) 它是一个 unsupported 且 undocumented 的东西，但是它希望实现的却是个巧妙的玩意。
今天 lua 5.1 rc4 发布了。看了一下，比较 rc3 只改了两个地方，一个是 luaconf.h 里的 lua_popen 的宏。还有一个是增加了 hex number 的支持。
前两天在 mailist 里讨论了这个问题，其实早就有呼声加上 16 进制数了。其实我自己也写过 patch 加上，lua maillist 里 Roberto 提了个方案，只需要修改 luaconf.h 里的 #define lua_str2number(s,p) 这个宏就可以了。我测试了一下，很巧妙，还顺手附和了两句。
不过这个方法对 16 进制数前面加了负号是有问题的（虽然我认为一般不会这么用），结果还是对词法分析代码打了 patch，改动不大，而且同样也很巧妙。Roberto 这次很大方，这么快就加到官方版本并发布了。
这次因为这么小的改变就发布新的 rc ，看来 lua 5.1 的正式 release 很近了。期待，这样 lua 就拥有了官方的模块化解决方案。
当程序逻辑交给脚本跑了以后，C/C++ 层就只需要把必要的输入信息传入虚拟机就够了。当然，我们也需要一个高效的传递方法。
以向 lua 虚拟机传递鼠标坐标信息为例，我们容易想到的方法是，定义一个 C 函数 get_mouse_pos 。当 lua 脚本中需要取得鼠标坐标的时候，就可以调用这个函数。
但这并不是一个好方法，因为每次获取鼠标坐标，都需要在虚拟机和 native code 间做一次切换。我们应该寻求更高效的方案。
前段把自己的虚拟机和编译器完成后，曾经和 lua5 做过一个比较。比较的结果很沮丧，我的虚拟机只能达到 lua 5 一半多点的速度。所以很不服气的又读了一段 lua5 的源码。而之前我是一段一段的看 lua source code 的，甚至 lua 4 和 lua5 的是在不同时期去读的，当然我也知道其间巨大的不同。
今天把脚本虚拟机整合到正在开发的引擎中去了，按新引擎的跨平台2进制格式 build 出来，只有 12.6K :D 比 lua 小多了 ^^ 庆祝一下。如果不是现在机器都是 32位了，在 16 位或者 8 位机上，这代码体积还能更小。唉，早几年计算机的地址空间只有 64K 的时候多痛苦啊。
突然想，我们这套引擎给手机用一定很不错 尤其是 gc 部分，比 lua python 什么的更适合小内存环境，可惜我现在对嵌入式开发没啥兴趣。
最近在做的一个虚拟机是基于垃圾回收(garbage collection)的，采用的是标记整理算法。这种算法的好处在于不需要 太多额外的内存，而且可以将内存中的 garbage 完全压缩掉。至于长期占用的内存空间，会被压到内存块的底部，整理时无须移动。
对于需要长期稳定运行的服务器程序，在 32bit 操作系统下，受限于有限的地址空间， gc 技术是根本解决内存碎片问题的最佳通用方案。
我计划在服务器程序中，全部程序逻辑都放在虚拟机内运行。由于和 client 程序不同，不用太考虑物理内存的占用，所以计划在服务启动的时候就预设 1~2G 的内存块供虚拟机使用。在这个内存块耗尽之前，所以涉及内存分配的操作都会相当的快了。但是一旦发生 gc ，光是扫描一遍内存，都是非常耗时的。所以我不得不考虑解决方案。
最初设计虚拟机时，bytecode 中的函数调用会产生一个 native code 上的实际的函数调用。似乎这样写比较容易。但是这样做，想实现bytecode单步运行却很困难。只有另开一个线程监护跑虚拟机的线程，在每步运行后可以挂起，而不破坏相关的堆栈。
所以，我想实现一个系统堆栈无关的虚拟机。
最近的工作是给虚拟机加上字符串类型的支持，并让编译器可以生成相应的 bytecode 。思路很简单，就是按 lua 的方式，把所有源码中相同的字符串合并，在 bytecode 中只保留一份。所有提到这些字符串的地方直接对其引用。bytecode运行时，产生的任何新的字符串都会产生新的副本。垃圾等到 gc 时回收。
想起来容易，实现起来还是颇为麻烦的。
今天，脚本编译器连同前段写的虚拟机全部完工了，很有成就感。
跟 lua 一样，复杂的数据类型我只支持了 table ，这个 table 即可以做 array 也可以做 hash_map 用。一般用 lua 的人都会用 table 去模拟 class 。lua 只对这个做了非常有限的扩展：在 lua 的文档中，我们可以看到
function t.a.b.c:f (...) ... end 可以等同于 t.a.b.c.f = function (self, ...) ... end
就我用 lua 的经验，这个转换用途不是特别大，只是少写个 self 而已。
这次我自己设计脚本语言，针对脚本支持 OO 的问题，特别做了些改进。
脚本虚拟机前段时间就已经做好，如果没有跑在上面的语言，光有虚拟机没太大意义。所以脚本编译器一早就开始做了。中间因为去上海参加 C++ 大会，又去了成都做招聘，弄的心力疲惫。这几天才回来，有那么几天去实现。
编译原理的课程大学本科就应该开过吧，我不是科班出身，反正是没正经上过。不过依稀记得自己是学过的，记得是上中学的时候，跑到一个大学上课，老师教的就是编译原理。那个时候 C 语言还没玩转，最熟的是 basic 和 6502 汇编。理解那些东西很有困难。囫囵吞枣的记了一点，算是有点印象，逢人也可以吹吹牛。
在编程的世界中，只有你想不到的事情，懒的做的事情，没有做不到的事情。
曾经一度为使用哪种脚本嵌入游戏犯愁，lua 的源码过了几遍，python 的也看了点。lcc 也试过，还有 ch 什么的。真正用在项目里的就是 lua 和 python 了。我个人更偏好 lua 一点。越读它的 source code 越觉得它作为世界上最快的脚本语言，是名副其实。
很早以前，我觉得显示一个图片很难，好象发现很简单。曾经觉得汇编很难，结果发现很简单。曾经担心 C++ 太复杂学不会，现在已经感觉游刃有余了。还有学习 perl php 或者是 stl mfc 这样的库，不懂的时候都觉得难，懂了却是不过如此。
对于游戏，说什么掌握 3d ，网络编程，无非是些技术方向而已。肯花时间，一定没问题的。
这次是脚本虚拟机。已经想了很久了，怕太复杂需要投入过多时间和精力。可事实上，写起来却又一次发现不过如此。
lua 的整体效率是很高的，其中，它的 table 实现的很巧妙为这个效率贡献很大。
lua 的 table 充当了数组和映射表的双重功能，所以在实现时就考虑了这些，让 table 在做数组使用时尽量少效率惩罚。