云风的 BLOG

那么，如果我原本就预期一段 C 代码会运行很长时间，有没有可能从底层支持以非阻塞方式运行这段代码呢？即，在这段代码运行期间，该服务还可以接收并处理新的消息？

在很长时间里，我认为在保证前面说的严格约束条件下，无法实现这个特性。这个约束就是，skynet 的服务必须以串行方式运行。但最近，我发现其实用一点巧妙的方式，还是有可能做到的。但我们需要重新审视约束条件。

我们约束了 skynet 的单个服务以串行方式运行，指的是，所有对服务 context 的操作都是串行的。如果是一个 Lua 服务，这个 context 应包括 Lua VM 。但是，如果一个需要长期运行的 C 函数并不需要访问 context （包括 Lua 虚拟机），而实现者自己能保证函数自身没有竞态问题，那么，在运行这段代码的同时，让另一个工作线程继续处理同一个服务，其实是满足条件的。

假设让 skynet 提供两个函数：skynet_yield() 和 skynet_resume() 。

当我们调用 yield 时，通知框架结束当前服务的时间片。这时，该服务的工作线程阻塞在服务的回调函数上，但我们依然可以关闭时间片。同时，框架可以额外启动一个备用的线程，补充临时减少的处理能力。这个服务被放回调度队列中，运行其它工作线程处理它的后续消息（即，可以继续调用服务的处理函数）。

等长期任务执行完毕，它并没有离开同一个工作线程的同一个 C 调用栈，但这时调用 resume ，框架则去检查当前服务是否正在被其它服务处理。如果有，等其它处理线程处理完毕后，不要归还服务进调度队列，由 resume 调用者继续后续的流程。

这样，我们通过 yield/resume api 拥有了在不离开当前工作线程而临时切分时间片的能力。只要实现者自己保障 yield 和 resume 之间的线程安全问题就够了。

从 Lua 的角度看，如果预期一个 C 函数调用可能是长期的，那么就在这个 C 函数中加入 yield 和 resume ，隔开耗时的部分，并保证被隔出的部分不会访问 Lua 虚拟机即可。

对这种特制过的 C 函数的调用，使用上看起来就是远程调用了一个系统服务，让出了 Lua 虚拟机并等待回应。但这个系统服务实际上是在当前的 C 调用栈上执行的。

这种略显诡异的方法，其实我在 ltask 中就实现过 。

接下来如果我给 skynet 增加这个特性，看起来可以做到之前难以完成的任务。

比如说，网络线程其实可以实现为一个常规服务，而不必像现在这样放在 skynet 的内核中。目前这样做是因为网络处理部分会阻塞在 epoll 的 wait api 上。当等待新的网络消息期间，它无法正常处理 skynet 的内部消息。

一旦有这样的特性，我们只需要把 wait 夹在 yield 和 resume 之间就可以了。

封装一些现成的自带阻塞 api 的 C 库也会更容易：我们可以直接接入官方的 db driver ，而不必把它们的 io 部分换成 skynet 的专有 api 。