共 4 篇相关文章
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题：如何在主线程事件循环中执行特定任务，同时仍保留原有多线程调度模型。 问题的核心来自图形 API 和平台约束。sokol 并非线程安全，OpenGL 又依赖当前线程状态，而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。 作者的解决思路不是重写整个调度器，而是在 ltask 中“打洞”：让某些必须在主线程回调中执行的 Lua 任务，临时从调度表中移出，由主线程接管执行，完成后再归还给调度器。 文章最有价值的地方，是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读，但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
笔者最早接触的是Condor/HTCondor，搞过网格计算的同学应该比较了解；Goolge的Borg应该算是一开始借鉴了很多Condor的东西，Omega则是在解决borg的单master调度的瓶颈问题；Tencent的Tborg/Torca则是和Borg系统有很深的渊源；Yarn和Mesos应该是被更多的人所熟知，都支持多种计算框架；对AutoPilot的认知更多来自于相关的论文；Baidu的系统其实蛮有意思，特别是IDLE（有个组件可以随意种植在任何机器上，当机器空闲的时候则调度一些低优先级并且可以随时K掉的计算任务上去执行，而且他们的PE人员身背机器利用率的KPI，大家都求着调度任务上去，这和咱们的现状完全是两样）；FUXI和T4是集团内的系统，大家想要了解可以在内网找到他们。
Erlang公平调度是它的哲学（或者说坚持）之一，从第一个版本的beam代码的时间片分配和抢占开始，到最近版本的bif对公平性的坚持（比如R17版binary_to_term就大幅做了修改，代码复杂很多，执行效率也有下降，但是在碰到大的binary的情况下，通过Trap机制会让出执行权，排队后再回来断点续作）， nif（加入扣除时间片的接口），这些努力保证了erlang系统是个公平的系统。 很多终端系统和业务会受益于这个哲学，如云计算。不管用户大小和业务的负载情况如何，系统性的公平性可以保证每个用户有机会被服务，对用户有很好的体验。
I/O 调度算法再各个进程竞争磁盘I/O的时候担当了裁判的角色。他要求请求的次序和时机做最优化的处理，以求得尽可能最好的整体I/O性能。在linux下面列出4种调度算?FQ (Completely Fair Queuing 完...
