10 年前
刚有微博的时候，我曾经信过互粉群
（摊手）

您要找的是不是：




.net framework

@squancher 所以说了，没有。你看起来的“实时” 就 就 就是先把状态改了等下一个时间片而已

下一个时间片分不到定时器就是不准的。就这样。

@squancher 状态改变是主动的，实时发生的，但检测状态改变，不是。

或者说 上面用户态的绝大多数情况都不需要实时感知直接触发回调

@squancher 内核中有专门结构，进程内会通过 api 来通知内核修改内核对象的值。

@squancher 假设我们实现一个慢悠悠的，没有优先级的，分片很长的调度方法


那，阻塞这件事就会变成（ A 等待 B 进程，系统有 ABCD4 个进程）
1. A 进程进入等待状态，调度器把 A 关联到 B，A 变为不可调度
2. 调度 B 进程，B 进程获得时间片，跑 1 秒，任务没结束。
3. 调度 C 进程，C 进程获得时间片，跑 1 秒
4. 调度 D 进程，D 进程获得时间片，跑 1 秒
5. 调度 A 进程，A 进程不能调度，继续选下一个
6. 调度 B 进程，B 进程获得时间片，跑 1 秒任务结束
7. 调度器发现 B 进程结束了，遍历正在等 B 的进程，发现 A，A 设为可调度
8. 调度 C 进程
9. 调度 D 进程
10. 调度 A 进程，A 进程获得时间片，取得 B 状态，跑 1 秒
11. 调度 B 进程，B 进程所有关联的等待者已不再等待，可以卸载 B 进程
12. 调度 C 进程

……

@squancher

> 就是这个问题，上面问过了，怎样判断条件，能做到实时，快速反应





不是“实时”的。
协程你理解吧，协程状态变化不是“实时的”对吧，而是被等待 routine 状态改变的时候调度器把等待进程重新设为可调度而已


进程一样的，操作系统判断被等事件状态可改变时把状态修改（为完成），同时把在等待这个事件的所有进程重新设为可调度，下次调度时就能恢复它们的执行流程



顺带一提，正因为 linux 调度器算法机制不能做到“实时”，所以 linux 并不是一个实时操作系统。RTOS 需要有硬件机制来直接通知内核立即切换进程状态并调度目的进程

努力是天赋的一部分


“别人都可以你为什么不行” 是蠢蛋逻辑，有认知能力的人应该会明白 “虽然我做不到 A，但我能做好 B”

c 太刀：刀片看着简单，但是招式花里胡哨，打得慢
java 重弩：爆发强，上满 buff 战撸一把梭
python 轻驽：用着很友好，力量有限，可以打辅助
c# 弓：用着很爽，输出也足，但一般都不会想作为主修武器
golang 斩斧：比 c 输出高，套路少，叠红刀无脑插爆（无脑 go routine ）
c 艹 盾斧：变化多机制复杂入门困难，但是能防反能超解能红斧锯个痛，打得慢。

不是踩一顶一。
但从大家的回复和反应来看

“中文编程” 是不是笑话，谁是笑话 一目了然

@BestSera
你游戏玩得真屌
你真玩个屌的游戏

rust 是来替代 c++的
c++有几个问题导致它“难用”

内存管理很容易爆炸
语法过于复杂，难学
模板过于无拘无束，以至于衍生了太多泛型以外的作用，写和维护都很爆炸
缺少现代的包管理 /build 机制

这几个问题里
内存，现代 c++基本已经自行解决，语言层解决不了的（如因为操作系统机制导致的泄露 /溢出） rust 也无法解决
难学和难维护的问题，rust 倒退了一步。看着封装好的宏的时候可能挺爽的，读别人的代码依然酸爽
包管理是 rust 对比 c++真正的优势，但在很长一段时间里仅仅是看起来机制更好，并不存在实际的优势。你发现想用的 package 依赖 nightly build 的 rust，依然会很难受


综上所述 估计 rust 并不有能力去淘汰正在激进地往语言里加现代特性的 c++


当 c++和 rust 能做的事和实现方式都差不多的时候，反正我还是选 c++

在北京我都摸着墙走路