无论是客户端还是服务器，把 lua 作为嵌入语言使用的时候，都在某种程度上希望把 lua 脚本做多线程使用。也就是你的业务逻辑很可能有多条业务线索，而你希望把它们跑在同一个 lua vm 里。

lua 的 coroutine 可以很好的模拟出线程。事实上，lua 自己也把 coroutine 对象叫做 thread 类型。

最近我在反思 skynet 的 lua 封装时，想到我们的主线程是不可以调用阻塞 api 的限制。即在主干代码中，不可以直接 yield 。我认为可以换一种更好（而且可能更简洁）的封装形式来绕过这个限制，且能简化许多其它部分的代码。

下面介绍一下我的新想法，它不仅可以用于 skynet 也应该能推广到一切 lua 的嵌入式应用（由你自己来编写 host 代码的应用，比如客户端应用）：

我们可以在第一个主模块加载时，在 skynet 中也就是 require "skynet" 这里，启动一个调度器的 coroutine 。

这个 coroutine 只用来管理一个数组，数组里全部是业务逻辑的线程。

这个调度器所属的 coroutine 对应的 lua_State 指针，应该记录在 lua vm 的注册表中，保证只到整个 vm 关闭前都活着，那么，接下来我们就可以放心的把它保存在 host 程序中了。

这样，在 host 程序中，除了原有的代表 vm 以及主线程的 L 之外，我们还有一个代表调度器 coroutine 的 cL 。

启动主逻辑的地方，在创建出 vm 后，通常是加载一个主程序文本，然后使用 lua_resume 运行主线程。如果主线程正常运行结束，则之后不再利用主线程 L 做任何事情；但若主线程被挂起，则把它加到调度线程管理的线程列表组里，之后当作普通业务线程去调度。

我们可以同时提供 lua 及 C API 来向这个数组添加新线程(coroutine) ，调度器的职责是永远在空闲的时候尝试 resume 新添加的线程，以及在外部 IO 消息抵达时去唤醒挂起的线程。这个调度过程中，原来的主线程和其它被创建出来的线程并无区别。

而调度器本身的算法并不需要太复杂，也完全没有必要用 host API 去实现，lua 来编写就完全胜任了。

有了这样的多线程机制后，我们可能还需要对 lua 原有的 coroutine 库做一点改造。改造后可以用业务层的 coroutine 和利用 lua coroutine 实现的线程库可以协同工作。 这个之前我已经写过一篇 blog 了 。