云风的 BLOG

在处理 lua_State *L 时，大部分人把 L 看成是 Lua VM 对象，实则不然。L 其实是一个 Lua thread ，而非 VM 。如果你把 set callback 时的 L 记录在 C 结构中，甚至用一个全局变量记录下来，是绝对错误的用法。因为 Lua VM 中可以有任意个 Lua thread ，调用 set callback 可以发生在某个 coroutine 中，而它是 gc 对象，未必能存活到 callback 被触发的时候。

记录 lua VM 创建时的 L 稍微好一点，因为这个 L 指的是 Lua VM 的 mainthread ，至少没有生命期错乱的问题，它能和整个 VM 共存亡。但是，这个 mainthread 的当前状态未必和 callback 发生时的 Lua 上下文能对应上。

因为，C 代码触发 callback 时，C 调用栈的源头，未必就是 Lua 的 mainthread ：很可能是在 Lua 的某个 thread/coroutine 中触发了 C 函数，进入了 C side ，然后 C 框架再触发的 callback 。此刻，mainthread 很可能出于某种挂起状态下。

举例来说：可能是在 lua mainthread 下 resume 了某个 coroutine ，这个 coroutine 进入了 C side ，然后触发了 lua callback function 。如果你拿出 Lua VM 的 mainthread 的 L 来用，它实际停留在 resume coroutine 处，Lua 栈状态处于挂起状态，直接使用它是非常不可靠的。至少，你必须用 lua_checkstack() 来保证 stack 的最小容量。

总而言之，lua_State *L 这个东西更像是 Lua 到 C 边界处的上下文，而非静态的对象，如果你跨越 Lua 和 C 的边界，不应该保留这个上下文。

如果有条件，不要在 C callback 中访问任何 lua VM 。尤其是 C framework 的 callback 若是跨越了系统线程，这就是必须的。最好的方法是把 C callback 的信息放到 C side 的队列中，然后提供一个 Lua function 可以拉取队列的数据以做处理。即：一切 Lua VM 都应在明确的时机、在明确的系统线程中运行。

但这个方案不适合 callback 有返回值的场合。

如果 C 的框架被设计成需要外部注入 callback 来获得某些用户定义的状态（注：我认为这样的框架属于不良设计）。那么应该考虑如何的方案来设计 Lua binding ：

在实现 lua side 的 setcallback 接口时，应该生成一个 userdata ，包含一个用 lua_newthread() 构造的独立 thread 的 L 指针。并把 thread 对象绑定在该 userdata 的 uservalue 上。

把 lua 的 callback function 置入这个独立新的 thread 的 L 上。如有必要，还可以在 L 上置入 lua_pcall() 所需的 error 处理 handler 。

将这个 userdata 的 C 指针放到 C side ，用于 callback 调用。管理好这个 userdata 的生命期，保证它可以活到 C side 的 callback 触发之后。

当 C callback 发生时，利用 userdata 中保存的 L 和 Lua 交互。调用事先保存好的 function 切记使用 lua_pcall() 。因为 lua callback function 就在这个 L 的 stack 上，所以，它比从 Lua 注册表中读回 callback function 还要高效。

具体实际案例，可以参考 skynet 这次所作修改。