首页 > 代码库 > skynet的协程

skynet的协程

之前对skynet的印象,主要是来自于我对golang的理解,对gevent开发的经验,以及云风的blog。对于底层的代码,并没有仔细去阅读过。最近在实现业务系统的时候,发现有同事在同一个函数里做了一个互斥的判断,才发现对skynet的理解有误。

 

以前,用python的gevent框架实现游戏服务器的时候,会针对每个玩家建立3-5个greenlet(协程),用于处理玩家身上的定时器事件,以及IO操作。然后还有少数几个协程处理全局的定时器事件。当然,战斗是放在独立的进程中实现的,那边基本上每个怪都有1-2个greenlet,一个房间里有几十个greenlet是很正常的。总结起来,就是python+gevent为了规避全局锁,采用了多进程,每个进程多greenlet的实现方式。

 

而对于golang,会变成底层是多线程模型,上面跑着多个goroutine,当一个goroutine发起阻塞式IO的时候,底层负责跑这个goroutine的线程,可以随之阻塞等待。系统便随即开一个新的线程,从一堆goroutine里挑一个可以执行的,继续执行。golang就相当于用多线程,取代了以前py的多进程。

 

读完云风的blog,我对skynet的理解,就是每个线程来跑一个Lua的VM,一系列的VM组成了一个队列。然后每个VM有自己的消息队列,VM运行时,就从自己的消息队列里,拿出一条消息执行。得益于Lua的沙盒机制,即使某个VM发生traceback,也能得到有效隔离。同时,因为同处一个进程内,VM之间数据交互可以做到相当高效,字符串之类的传递只要传指针即可。

 

但是,我之前忽略了Lua协程在其中发挥的作用。原来,一个服务(即一个VM)收到一个包req,就会新建一个协程进行处理。处理过程中,如果产生一个对外的call请求,req包是当成处理完的,当前的协程是会刮起,等待call请求返回来唤醒。这时候服务可以继续建立新的协程来处理新的消息包,而不会阻塞住。也就是说,如果处理一个包的过程中,发生了skynet.call调用,是会造成多个协程并发执行的。如果不注意用锁保护协程间的共享资源,就有可能出现问题。

skynet的协程