重写Sylar基于协程的服务器（4、协程调度模块的设计）

本文主要是介绍重写Sylar基于协程的服务器（4、协程调度模块的设计），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

重写Sylar基于协程的服务器（4、协程调度模块的设计）

重写Sylar基于协程的服务器系列：

重写Sylar基于协程的服务器（0、搭建开发环境以及项目框架 || 下载编译简化版Sylar）

重写Sylar基于协程的服务器（1、日志模块的架构）

重写Sylar基于协程的服务器（2、配置模块的设计）

重写Sylar基于协程的服务器（3、协程模块的设计）

重写Sylar基于协程的服务器（4、协程调度模块的设计）

重写Sylar基于协程的服务器（5、IO协程调度模块的设计）

简述

协程调度模块：让线程池里的每个线程都运行调度协程，并不断切换去执行协程任务。

协程调度器整体架构图

sylar实现的协程是非对称协程，虽然就调度器的架构看来，很反人类，一眼看去很像是对称协程。

问了一下GPT，回答如下：

实现了 IO Hook 模块的协程通常是非对称协程模型。在异步编程中，IO Hook 通常用于异步 IO 操作，而非对称协程模型更适合处理异步 IO 操作。

在非对称协程模型中，一个主协程（通常是事件循环或主任务）可以通过 IO Hook 来注册感兴趣的 IO 事件，并在事件发生时启动相应的协程执行。这样的模型更适用于事件驱动的编程，其中主协程负责管理整体的控制流，而子协程负责处理具体的 IO 操作。

协程调度器模块的设计是基于线程池来完成的，对线程池进行协程的定制化改造，让线程池模型能够适应协程的切换，如图：

调度器架构

协程调度模块设计

构造函数，用户创建协程调度器主要的参数有，设置参与协程调度的线程数量threadCount、主线程是否参与协程调度等，构造函数首先会为主线程原始的上下文创建一个协程（t_threadFiber），其次，如果用户指定了主协程需要参与协程调度，就会为成员变量m_rootFiber创建一个回调函数是Scheduler::run()的协程，并且指定该协程与t_threadFiber做上下文切换。主线程等待后面延迟将m_rootFiber切入，进入Scheduler::run()函数后，t_threadFiber保存主线程原始上下文，t_schRunFiber赋值为m_rootFiber即运行Scheduler::run()函数的协程。而子线程运行的回调函数就是Scheduler::run()函数，所以，子线程的t_threadFiber和t_schRunFiber是同一个协程对象。并且，因为主线程充当了一个调度协程，所以，创建子线程的时候，会少创建一个线程，即子线程的数量等于threadCount-1。当用户没有要使用主线程充当调度协程时，调度器最后会创建threadCount个子线程。
Scheduler::run，协程调度部分，进入调度函数最开始会初始化t_threadFiber和t_schRunFiber变量，然后进入调度循环，在调度循环中，首先到任务队列中取任务，取到任务时，判断任务是协程还是回调，如果是协程，判断协程状态的合法性，只有合法的协程才能切入去执行，对于回调，会被封装成协程，再切入去执行。如果没有任务，就会去执行idle协程，idle协程是IO协程调度模块的重点，主要负责等待事件的到来然后唤醒相应任务协程。

协程调度函数Scheduler::run伪代码：
Scheduler::isStop，当用户调用了成员stop函数，且任务队列队列为空，且没有任何线程正在执行协程任务，即可认为整个协程调度器停止了，此时该函数返回true。