dvsilch

举个例子：游戏业界逐渐开始使用的 ECS 架构就是以面向数据编程为核心搭建
具体介绍看 https://github.com/SanderMertens/ecs-faq

@LaTero Unity 7 前几天刚说要 Unified Rendering 了，但感觉也得过一两个 LTS 才能用

@songunity 老项目咋用华佗啊，拆 dll 拆到死

3999 拿下无界 15x 暴风雪，屏幕颜色有点偏黄得自己调，键盘背光的设置也有点问题（关闭了但时不时会被恢复成打开的状态，而且开机时设置不管用一定会亮，估计不是写进 bios 里的？），只有白色外观让人不爽，除此以外都挺不错的

@tsanie
是我笔误了，确实是 CancellationTokenSource(cts)，C#里可以做到外部内部各提供一个 cts ，初始化时将两个 cts link 然后将 ct 链式传递到各个异步任务，需要中断时任意一个 cts 直接 cancel 即可，会立刻走到 catch OperationCanceledException 的分支

但我看了一下 AbortController 似乎只能做到对 fetch api 执行中断，不是特别符合我当前的业务场景...不仅仅是网络请求，还有一些文件的读取、以及等待用户另外输入的 Promise 。这部分如果取消不掉的话，我能想到的形式就是要么把各个 reject 动态推入移出队列，要么就是每一轮异步任务结束后判断状态。两种做法都感觉不太合理，所以目前的做法是暂时跟 #9 #15 一样写一个自定义的 generator 来统一这部分逻辑，有空再去研究研究 rxjs 的实现

@jones2000 是的，其实跟上面使用 generator 的思路一致

@pursuer
@amlee
看了下，AbortSignal 大概也需要在没做支持的异步任务上套一层 Promise 或者每次异步结束前做状态检测，也不是很好

@rabbbit
@Projection
rxjs 之前也有看过，无奈确实是经验不够一眼瞎。目前看来对我而言修改起来最简单的方式，就是自己写一个 generator 然后来手动判定是否执行下一步了，至少把状态判断统一在了 for 循环里，少写不少东西

@chenliangngng
@DOLLOR
@pursuer
不好意思主贴里没说清楚，代码里的状态只是随便写了一个东西，实际业务并不是这么实现的。而且，与其说会因为状态出现 bug ，更不如说是我感觉这种「每次异步任务后需要主动判断状态」的做法太傻逼了...

@rabbbit 这个方式我之前实现过，但是存在麻烦的地方是：业务场景需要外部和内部都拥有 cancel 的能力，结果就是需要暴露一个额外的方法同时内部持有这个 reject ，担心会出现因为持有 reject 导致 promise 无法从内存中释放的情况