本篇主要内容
- 讲解使用Skynet中逻辑挂起，恢复，以及坑点
建议提前掌握的知识
- Lua协程
什么是挂起
简单的来说，就是代码的逻辑可以暂停，直到被唤醒，然后接着暂停时逻辑继续执行。
Call的设计
在上一章我们讲到service之间的消息发送方式有两种，分别是call和send。
send的设计没什么选择，基本就是发目标一个消息，然后不关心返回值，继续做自己的逻辑。
call的设计就有两种了:
- 基于send来做，调用接口时指定一个函数，等结果返回的时候，执行这个函数，比如nodejs中就是这么干的。
- 基于挂起来做，调用后暂停当前的逻辑，等有返回值，继续执行接下来的逻辑。
从个人的角度，特别是在被nodejs中callback机制恶心过后(感兴趣的话可以搜索一下callback hell)，我坚定地认为第二种方式令人更舒服，这也是Skynet中call的方式。
Lua协程中的挂起与唤醒
下面这段代码演示下lua协程的挂起和唤醒的过程
local share_value = 0
-- 创建多个协程，每次被唤醒时打印下自己的编号，然后挂起
local co_num = 2
local co_list = {}
for id=1, co_num do
local func = function()
while true do
share_value = share_value + 1
print(string.format("coroutine %s, share:%s", id, share_value))
coroutine.yield()
end
end
table.insert(co_list, coroutine.create(func))
end
-- 主线每隔一段时间，就唤醒所有的协程
local max_loop = 3
for idx=1, max_loop do
print(string.format("main thread, loop:%s", idx))
for _idx, co in ipairs(co_list) do
share_value = share_value + 1
print(string.format("main thread, share:%s", share_value))
coroutine.resume(co)
end
end
print("main thread, end")
运行结果：
main thread, loop:1
main thread, share:1
coroutine 1, share:2
main thread, share:3
coroutine 2, share:4
main thread, loop:2
main thread, share:5
coroutine 1, share:6
main thread, share:7
coroutine 2, share:8
main thread, loop:3
main thread, share:9
coroutine 1, share:10
main thread, share:11
coroutine 2, share:12
main thread, end
上面的例子中，轮到协程运行时，它做完自己的时候后会挂起自己。轮到主线程的时候，它会挨个唤醒其他协程。
在轮到自己运行时，还会去给变量share_value加1，从运行结果可以看出，
share_value是共享的，但又不像多线程需要用锁保护一下共享资源，在同一个lua虚拟机中，同时最多只会有一个协程在运行。如果细想一下，马上意识到协程虽然相对多线程方便很多，但是还有坑的。(如果暂时没想到，可以先思考下再看后面的内容)
坑就在脚下
Skynet中，service的每一个消息处理过程，都是在一个协程中进行。在处理的过程中，当发生call其他service的操作时，对应的协程会挂起，直到接收方处理完以后返回。如果接收方的逻辑traceback了，发送方对应协程也会traceback。但如果接收方再也不返回了，比如没有写Skynet.retpack()，或者陷入了死循环, 那么发送者对应协程会一直挂起(目前的版本标准的call没有超时机制，如果实在想做这样的逻辑，也有其他办法)。除了call还有一些操作导致挂起，比如sleep，wait等。
下面，我们举几个例子说明下挂起可能引发的问题：
第一个例子
假设有一个购买东西的需求，这个东西需要远程的service处理，并且需要消耗一些金钱，下面是个有问题的写法
-- 伪代码
function buy(good_id)
-- 第1步
根据商品ID获取商品价格
-- 第2步
if 玩家没有足够的金钱 then
return 金钱不足
end
-- 第3步
向远程的服务请求购买
-- 第4步
if 购买失败 then
return 金钱不足
end
-- 第5步
扣除玩家的金钱
给玩家奖励
return 购买成功
end
第3步中，由于购买操作是一个远程服务Call操作，会引起挂起，有返回值时(被唤醒)，上下文可能变化。这意味着第5步中，扣除玩家金钱操控是不受第2步保护的。
也许有人会说金钱是可能会用在很多接口里面，如果是一个玩法专属的资源，并且只有一个接口可以操作它，比如票数之类的是不是就不会有问题呢？还是不行，因为虽然只有一个接口，只要但同一时间发很多相同的请求(比如利用网络延迟)，还是可以刷物品。
第二个例子
有些service是针对一种业务，但是很多个玩家的，比如邮件系统。接口基本都是一个玩家角色uuid为key，但由于一个服的玩家很多，不可能在开服的时候，直接把所有玩家的信息都从数据库都加载进内存，也不想全部依赖数据库，因为做复杂逻辑时很不方便。于是打算做个DB缓存，用到的时候拿出来，然后根据一定策略放回去(比如最近访问时间等的)。由于访问数据库是一个call操作，所以加载时会遇到类似的问题
-- 伪代码
function CacheMgr:load_player(uuid)
-- 第1步, 如果缓存中有，立即返回
local obj = self.cache[uuid]
if obj then
return obj
end
-- 第2步，从数据库中查玩家数据,
local data = self.db:load_player(uuid)
-- 第3步，根据db的数据初始化对象
obj = self.create_obj(data)
-- 第4步，设置cache
self.cache[uuid] = obj
-- 第5步，返回cache对象
return obj
end
由于第2步中的Call操作会引起挂起，意味被唤醒后，第1步的结论，即缓存中没有这个玩家的结论已经不靠谱了。如果第4步，直接设置，可能会导致cache中已经有对象被新对象覆盖，导致数据丢失。
其实无论挂起的方式还是回调函数的方式，都会遇到上下文变化的问题，这是高效率的并发机制下必然会遇到的问题，否则只能改为一个一个顺序处理消息了。服务端开发天然地存在不同线程的并行问题，然后又带了同一个线程下的并发问题，挂起的概念虽然很简单很好理解，但却是最容易导致bug的地方，当然也是最烧脑最有趣的地方。
编程挑战(欢迎你留言和我讨论)
- 上面的两个例子，怎样写才合理
- skynet.wait和skynet.wakeup分别是触发当然协程挂起和唤醒指定协程的接口，用这两个方法写一个协程级别的锁(可用于多个协程的挂起逻辑保序)
