IT牛人博客聚合

最近几天优化了一下 pbc 。

这是一个大改动，所以写 blog 记录一下。

首先，我为 rmessage 定制了一个 heap alloc ，在使用 rmessage 解包的时候不再调用系统的 malloc 。而是从一个连续内存 heap 上取用内存。这样在删除 rmessage 对象时也会更快。因为只需要把 heap 回收即可。

当然这样会导致 rmessage 解包时用到的内存增加。对于内存紧张，性能关键部分，我还是推荐 pattern 模式。虽然比较难用，但可以保证时间和空间性能。

另外，我增加了 upb 的 Event-based parsing 模式，见新增接口 pbc_decode 。

不过我认为这个 ap

查看全文: http://www.udpwork.com/item/7185.html

如果你在同一个进程里有多个 lua state , 它们需要共享大量的只读数据, 那么可能就不希望在每个 state 启动的时候都加载和解析一遍这些数据.

所以我们需要一个共享只读数据的方法。

前段时间，我实现了一个 共享内存服务 ，这个可以保证共享内存的安全读写。不过，如果数据是只读的，那么就不需要这么复杂了。

我们只需要把数据加载到一个 lua state 中，其它的同一进程内的 state 通过 C 接口去读数据就可以了。

今天，我做了简单的实现，放在了 github 上。

目前可以支持 nil number boolean function table 的数据交换。

function 交换有一些限制，不可以绑定

查看全文: http://www.udpwork.com/item/7138.html

虽然今天发了 twitter ，以及向 lua mailling list 里投递了消息，不过想想还是写一篇 blog 记录一下。

Lua 只支持一种 number ，默认是 double 类型。虽然你可以通过修改 luaconf.h 里的定义，把 lua number 改成 int64 。但是为了 int64 类型而放弃浮点数，恐怕不是大多数人想要的。

int64 通常用在 uuid 上，也就是说不需要对其数学运算，只需要可以比较就好了。我以前最喜欢的做法是用 8 bytes 长的 string 来表示一个 int64 。这样，即可以做唯一的 key 用，又不用做复杂的扩展。

在 pbc 的 lua binding 库 中，

查看全文: http://www.udpwork.com/item/7108.html

我们用 lua 做主要的项目开发语言，一直有同学希望可以在 IDE 里单步跟踪调试 lua 代码。我总觉得这个坏习惯是被 Windows 带坏的。当然，很多年前，我也尝试过编写一个图形界面的 debugger 。后来这玩意半途而废了。因为我觉得没啥实用价值，需要这样去调试 lua 程序的程序员反正也写不好 lua 程序。宁可不要这种工具让 lua 程序员的代码质量能提高一点。

后来过了两年，还在网易时，又有同学要求有一个方便点的调试器。我又写过一个远程调试器，gdb like 的界面，用 C/S 方式调试，并用 GTK 配了一个 GUI 的 client 。主要就是远程设置断点，观察变量等。有兴趣的同学可以看这一篇。

这套东西

查看全文: http://www.udpwork.com/item/6857.html

今天花了将近 3 个小时帮同事看一个崩在 lua VM 中的 bug 结果打乱了进度，没有在年前把预想的东西做完。其实说起来这不是个大问题，以前也碰到过。我检讨自己没有在看到出错时的调用栈时去看一眼 lua 相关的代码。如果是那样，因为以前遇到过同样的问题，所以就可以条件反射出问题原因，而不用荒废宝贵了数小时时间了。

唉，这下整合的进度没接上，过年不能自己一个人接着做下面的活了。

下面记录一下这个 bug ，提醒自己第三次遇到时不用再花时间找问题：

问题的缘由是因为的不同的 lua 扩展库链接的时候多链接了一份 lua 库，导致进程内有超过一份 lua 库。这是在写 Makefile 时不小心造成的。知道原因后自然很容易解决。

查看全文: http://www.udpwork.com/item/6725.html

lua 5.2 正式发布了，对于 lua 语言本身的修改，重中之重就是对 environment 这个概念的修改。

可以说， 5.1 以前的 environment 已经没有了。environment 对于制造一个安全的沙盒（或是实现 DSL）是一个很重要的语言特性，我以前很喜欢使用，但也很容易用错。这次的修改我认为是一个谨慎的决定，并使得 lua 语言更为精简和严谨了。

我这样理解 5.2 中的 environment 。本质上，lua 取消了原有意义上的 environment 。所以我们可以看到 C Function 不再有环境了。function 、在 lua 中称为 closure ，仅仅只是函数体和 upvalue

查看全文: http://www.udpwork.com/item/6598.html

前几天写的 pbc 初衷就是想可以方便的 binding 到动态语言中去用的。所以今天花了整整一天自己写了个简单的 lua binding 库，就是很自然的工作了。

写完了之后，我很好奇性能怎样，就写了一个非常简单的测试程序测了一下。当然这个测试不说明很多问题，因为测试用的数据实在是太简单了，等明天有空再弄个复杂点的来跑一下吧。我很奇怪，为什么 google 官方的 C++ 版性能这么差。

我的 lua 测试代码大约是这样的：

local protobuf = require "protobuf"

addr = io.open("../../build/addressbook.pb","rb")
buffer = addr:

查看全文: http://www.udpwork.com/item/6526.html

几个月以前，在我在 blog 上曾谈及 Lua 5.2 的改进。它可以用来实现抢占式多线程 。

周末休息，我把这桩事挖出来娱乐一下，花了一整个晚上做了实现。把 lua 的每个线程锁定在独立的 lua state 中，强迫线程之间通过消息管道的方式通讯。经过测试，Lua 5.2 每个独立的 state 占用的内存很小。通过自定义 alloc 函数可以测算出，一个干净的 32bit state ，不含任何库函数时，占用内存量在 2K 以下(1726 bytes)。如果加载基本库，也仅仅占用不到 4K (3265 bytes)。若把所有 lua 官方标准库加载进来，才会上升到 10K 以上(12456 bytes)。

对于 luaji

查看全文: http://www.udpwork.com/item/6264.html

Lua 5.2 的开发进度可以回溯到 2010 年 1 月。漫长的流程到今天已经快两年过去，终于等到了 beta 版。我十分期待它可以在 2011 年内正式发布。在这几经折腾的两年里，许多新特性企图挤进 5.2 版，又最终被否决。

当我们审视改进列表，似乎看不到太多耳目一新的东西。但如果仔细阅读一下源代码，就会发现，大部分地方都重新实现过了，以配合这些表面上看起来不大的修改。如果你对 Lua 有足够理解，会发现，这次最激动人心的改进是 "yieldable pcall and metamethods" 。官方也把之列为 Main changes 第一条。语言上的重大新特性 goto 却被列在末尾。

当然，这只是我粗浅的理解而已。

查看全文: http://www.udpwork.com/item/5616.html

最近 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 的负担。从某种角度可以看到另

查看全文: http://www.udpwork.com/item/5347.html

前几天分析了 lua gc 的实现细节。这里先汇总一下：

Lua GC 的源码剖析 (1)

Lua GC 的源码剖析 (2)

Lua GC 的源码剖析 (3)

Lua GC 的源码剖析 (4)

Lua GC 的源码剖析 (5)

Lua GC 的源码剖析 (6)

btw, 阅读 lua 的代码是段很有趣的经历。但如果是重头读 lua 的源码，建议从简单的部分读起。gc 恰巧是最难的一段。LuaJIT 的作者 Mike 在这方面很有发言权，他在回答 Which OSS codebases out there are so well designed that you would consider them 'must re

查看全文: http://www.udpwork.com/item/4719.html

今天来说说 write barrier 。

在 GC 的扫描过程中，由于分步执行，难免会出现少描了一半时，那些已经被置黑的对象又被修改，需要重新标记的情况。这就需要在改写对象时，建立 write barrier 。在扫描过程中触发 write barrier 的操作影响的对象被正确染色，或是把需要再染色的对象记录下来，留到 mark 的最后阶段 atomic 完成。

和 barrier 相关的 API 有四个，定义在 lgc.h 86 行：

#define luaC_barrier(L,p,v) { if (valiswhite(v) && isblack(obj2gco(p))) \
luaC_ba

查看全文: http://www.udpwork.com/item/4695.html

今天来看一下 mark 过程是怎样实现的。

所有的 GC 流程，都从 singlestep 函数开始。singlestep 就是一个最简单的状态机。GC 状态简单的从一个状态切换到下一个状态，循环不止。状态标识放在 global state 的 gcstate 域中。这一点前面谈过。

开始的两个状态和 mark 过程有关。

初始的 GCSpause 状态下，执行 markroot 函数。我们来看一下 markroot 的代码。见 lgc.c 的 501 行。

/* mark root set */
static void markroot (lua_State *L) {
global_State *g = G(L);

查看全文: http://www.udpwork.com/item/4689.html

有了前几天的基础，我们可以从顶向下来读 lua gc 部分的代码了。

我们知道，lua 对外的 API 中，一切个 gc 打交道的都通过 lua_gc 。C 语言构建系统时，一般不讲设计模式。但模式还是存在的。若要按《设计模式》中的分类，这应该归于 Facade 模式。代码在 lapi.c 的 895 行：

/*
** Garbage-collection function
*/

LUA_API int lua_gc (lua_State *L, int what, int data) {
int res = 0;
global_State *g;
lua_lock(L);
g = G(L);
switch

查看全文: http://www.udpwork.com/item/4665.html

早期的 Lua GC 采用的是 stop the world 的实现。一旦发生 gc 就需要等待整个 gc 流程走完。如果你用 lua 处理较少量数据，或是数据增删不频繁，这样做不是问题。但当处理的数据量变大时，对于实时性要求较高的应用，比如网络游戏服务器，这个代价则是不可忽略的。lua 本身是个很精简的系统，但不代表处理的数据量也一定很小。

从 Lua 5.1 开始，GC 的实现改为分步的。虽然依旧是 stop the world ，但是，每个步骤都可以分阶段执行。这样，每次停顿的时间较小。随之，这部分的代码也相对复杂了。分步执行最关键的问题是需要解决在 GC 的步骤之间，如果数据关联的状态发生了变化，如果保证 GC 的正确性。

查看全文: http://www.udpwork.com/item/4648.html

最近发现在大数据量的 lua 环境中，GC 占据了很多的 CPU 。差不多是整个 CPU 时间的 20% 左右。希望着手改进。这样，必须先对 lua 的 gc 算法极其实现有一个详尽的理解。我之前读过 lua 的源代码，由于 lua 源码版本变迁，这个工作还需要再做一次。这次我重新阅读了 lua 5.1.4 的源代码。从今天起，做一个笔记，详细分析一下 lua 的 gc 是如何实现的。阅读代码整整花掉了我一天时间。但写出来恐怕比阅读时间更长。我会分几天写在 blog 上。

Lua 采用一个简单的标记清除算法的 GC 系统。

在 Lua 中，一共只有 9 种数据类型，分别为 nil 、boolean 、lightuserdata

查看全文: http://www.udpwork.com/item/4633.html