58 lines
3.0 KiB
Plaintext
58 lines
3.0 KiB
Plaintext
|
||
c++20协程是可重入状态机
|
||
本质协程是未了灵活性把线程调度机制从操作系统搬到了用户态
|
||
协程的过程变成了 准备资源 -> 挂起等待（后台等待操作系统处理完成，或者其他线程处理完成）-> 拿到结果或者作为准备的资源进行挂起或者直接返回
|
||
整个调用流程变成了 网状 来回乱跳，怎么跳由调度器规则决定
|
||
|
||
问题就在于资源身上，不能假设控制第三方库调度器，那么协程必然是多线程的执行
|
||
而且资源未必只由操作系统api提供 gpu也是一种资源
|
||
|
||
|
||
每个资源有自己的使用要求，那么基本每个资源都要自己去改成支持多线程的
|
||
|
||
|
||
|
||
|
||
|
||
理论上可以基于 ucoro 实现协程的整合（第三方库使用自己的调度器） 外部再暴露出 stdexec::scheduler 形式的接口
|
||
|
||
内部：
|
||
ucoro 负责协程状态机 / awaitable / callback bridge
|
||
第三方：
|
||
Drogon / Asio / SDK / GPU 仍然用自己的调度器和资源规则
|
||
你的 runtime：
|
||
负责业务协程恢复位置、post 队列、shutdown、取消、线程归属
|
||
外部：
|
||
暴露 stdexec::scheduler / sender 风格接口
|
||
|
||
|
||
第三方库内部怎么调度，你不接管。
|
||
第三方库完成后，adapter 把结果搬回你的业务调度器。
|
||
你的业务层继续用 ucoro 或 sender 风格组合。
|
||
┌────────────────────────────────────┐
|
||
│ 外部接口 / 未来标准层 │
|
||
│ stdexec::scheduler / sender │
|
||
└─────────────────┬──────────────────┘
|
||
│
|
||
┌─────────────────▼──────────────────┐
|
||
│ psc::async facade │
|
||
│ task<T> / spawn / scheduler / error │
|
||
└─────────────────┬──────────────────┘
|
||
│
|
||
┌─────────────────▼──────────────────┐
|
||
│ ucoro 层 │
|
||
│ awaitable<T> / callback_awaitable │
|
||
└─────────────────┬──────────────────┘
|
||
│
|
||
┌─────────────────▼──────────────────┐
|
||
│ adapter 层 │
|
||
│ Drogon / Asio / SDK / GPU / File │
|
||
└─────────────────┬──────────────────┘
|
||
│
|
||
┌─────────────────▼──────────────────┐
|
||
│ 第三方库自己的 runtime │
|
||
│ trantor / io_context / worker / GPU │
|
||
└────────────────────────────────────┘
|
||
|
||
|