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 │
└────────────────────────────────────┘