@GeruzoniAnsasu

针对你的 task ，准备一个跟结果一直长度的 []chan 就可以了，扫一遍每个 channel 就可以针对每一个 chan 的阻塞策略，很直接。https://go.dev/play/p/YbtujcTry_J 。

至于 Promise ，你需要的只是一个 Task 结构，注意到结果本身是否 ready 可以依靠超时 + channel ，解决，封装一个类似的结构是 naive 的，在 github 上能找到非常多的类似的库。

可以去看一些官方 talk 理解 CPS 机制的原理，而不是尝试把某个机制 mapping 过来。

文件系统是对底层物理数据存储的抽象，本质上是一种协议，这些 section 上的数据可以用这种协议解释。在不同系统上使用同种协议可以挂载同一个区块，最终写完了都在同一个物理区块上，那么换到其他系统（甚至直接 `dd` 到一个 image ）上打开，只要协议一样，读取到的内容是一致的。

而 OS 本身跟文件系统是半解耦的：本质来说，OS 跟文件系统应该是完全解耦的，你也可以在 Linux 上使用 NTFS 。但是对于现在用的比较多的三大 OS ，都对自己常用的文件系统有特定支持（例如 Windows 的 Bitlocker 对 NTFS 支持最好，一些比较有意思的扩展特性例如 Alternative Data Streams 可能其他平台的 ntfs 实现不包含），所以本质上来说跟 OS 关系大也不大。

所以，文章的问题可以回答为：
- 保存在物理区块上，跟操作系统无关。
- 在不同操作系统下，只要有协议的实现或者兼容层，读写应该不会有太大问题。
- 现代 OS 对自己常用的文件系统可能大多有扩展，对于这些扩展，在其他平台的兼容实现上可能有问题。

Go 实际上编译生成的函数只是在语义层面上跟原始类型绑定，而在之后的代码生成过程中，Go 隐式生成了一个对应的函数，这个新的函数跟老的类型是解耦的，并把对象本身作为第一个参数传入。

举个例子来说，考虑你的测试代码，Go 编译器会生成下面的 stub：

```go
func (*A).Run(a *A) {
fmt.Print(a.a)
}
```

这种函数签名是你不能写出来的，因为在用户层面这种语法是 invalid 的，但是你可以调用。尝试在你的 Test 中插入：

```go
func TestA(t *testing.T) {
var a *A
a.Run()
}

func TestAnother(t *testing.T) {
var a *A
(*A).Run(a)
}
```

代码可以正常编译执行，然后报错。

而假如我定义另一个方法，不访问 A 的内部参数，即不依赖 A 的值，你会发现代码能够安全运行，没有任何问题（ 16 楼老哥已经有 runnable 了）。

这种情况是不是比较反直觉？而实际上 GCC 和 clang 也是这么做的： https://godbolt.org/z/xb9WWz53x 。当然，如果你打开 undefined behavior santizer ，你会发现编译器报错了，因为标准并没有对这个情况作出规定。

所以是否需要检查 receiver 是不是 nil ？取决于你。如果这个方法你不想 panic ，那你可以检查 `if p != nil` 并做出恰当报错，但是这会影响大家对于 method call 语义的共识理解（如果 a 为 nil ，我调用它的方法应该 panic 啊？为什么没有 panic ？）。或者直接 let it crash ，也方便查错。

续了三年，吃饭的工具还是愿意买单的，而且也确实好用，虽然我现在主要用的最多的也是 vscode 。

Ti7000 之前掉盘了，朋友的 PC005 自己用了帮别人装，一年多了没出过问题

@lxdlam 没有换行写的有点乱，最后一条 case 和 default 是不同的分支

Reading Material： https://go.dev/blog/pipelines

拆成两个问题：
1. 多个 goroutine 如何读取消息
- 使用 fan-in 和 fan-out pattern ，将其结果汇总到一个 channel 里，此时原始 goroutine 关闭 channel 不影响；
- 直接 select 多个 channel 。
2. 当某个 gorutine 退出时如何通知其他的 goroutine 退出：
a. （可选）如果需要等待其他 goroutine 退出的话，使用 sync.WaitGroup 等待；
b. 使用一个 exitChannel （ chan struct{} 就行），接收到退出信号的时候直接由 main close ，其他 goroutine 使用 `for { select { case <- exitChannel: return default: logic} }` 的形式来正确接受退出信号

尾递归跟迭代没有任何直接联系。

- 可以把尾递归优化成迭代并不意味着常规递归不能被优化成迭代： https://stackoverflow.com/questions/54686395/how-can-modern-compiler-optimization-convert-recursion-into-returning-a-constant 。
- 可以把尾递归优化成迭代同样不意味着尾递归一定会被优化成迭代： http://neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html

- `shared_ptr<T>` 的结构由两部分组成：control block 和 data block ，其中 control block 负责控制引用计数，并发安全，但是 data block 无任何并发安全保证。
- `shared_ptr<T>::unique()` 负责检查是否仅有一个用户在使用（即自己）。

所以这是一个比较简单的 CoW(Copy-oon-Write) pattern ，在需要修改时复制一份数据单独维护。

这个其实是一个很常见的策略，很多时候 pivoting 用到的知名工具都会被标记有风险，比如 frp ，chisel 等等

@bmpidev2019 废弃的原因其实是因为 Linux 的线程实现方式的历史原因。https://web.archive.org/web/20040211225937/http://java.sun.com/developer/technicalArticles/Programming/linux/

注意到：
> ... Each Linux thread is created as a process clone operation, which leaves the scheduling of threads to be a task of the process scheduler.

而彼时的 Linux 内核版本离 2003 年真正实现了内核态的抢占调度（ 2.6 版本，CFS 算法）还有 3 年，也就是说，这个时候的 Linux 只支持一个时间一个线程在跑，OS 无法主动抢占当前正在执行的线程，必须由用户侧程序来调用 schedule 。换句话说，这个时候创建的线程受到了 Linux Process Scheduler 的制约（ Linux Scheduler 调度的最小单元是 Thread ），无法实现真正的并行（操作系统无法调度到其他 CPU 上），同时，这样实现的 Thread 切换跟 OS Thread 切换是一致的，也受到 OS Thread 切换的制约（ Context Switch ，内核态-用户态进出）。

> By comparison, on Solaris the Java threads are mapped onto user threads, which in turn are run on Lightweight processes (LWP). On Windows the threads are created inside the process itself. For this reason, creating a large number of Java threads on Solaris and Windows today is faster than on Linux. This means you might need to adjust programs that rely on platform-specific timing to take a little longer on startup when they run on Linux.

正如你文章引用的 Solaris 调度系统图所说，Solaris 的调度存在 LWP 这个中间单元，这个中间单元其实类比于现在并发的 M:N 实现，实际是比较超前的。LWP 能被自由的调度到多个 Kernel Thread 上，多个 Kernel Thread 也可以被自由地调度到每个 CPU Core 上；而 Windows 的调度也是在 Process 的树形结构下调度的。在这两个系统下，由 JVM 实现的调度器能够自由地把 Task 进行低开销地切换（要么发生在 LWP 间，要么发生在 Process 内），系统调度的时候也不仅仅以 Thread 为单位（ LWP-Kernel Thread 或者 Process-Thread ），使得在这两个平台上，Green Thread 的调度都是合理的。

当然，随着后面 Linux 的崛起，Java 1.3 虽然放弃了 Green Thread 实现，但是 Project Loom 又把它带回来了，这也是 OpenJDK 认为的，Java 并发调用的未来。

@lxdlam 好像记忆出现了偏差，Project Loom 应该是 cooperative 的。

仍然是有问题的哈。

1. Go 的 Goroutine 在 1.14 之后就是基于信号抢占式调度的了（ https://go.dev/doc/go1.14 ），因为没有手动的 yield ，并不是 cooperative 的。
2. Java 的 Green Thread 已经在 1.3 之后被 Native Thread 取代，换句话说，现行的 JDK 的原生调度模型等同于 OS Thread 。Java 的新用户侧线程 Project Loom 会是新的 Green Thread 方案，但是仍然是抢占式调度的。
3. 由于硬件和软件的进步，Windows 的 Fibers 已经日渐式微了（ https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=102989 ），在日常讨论中常用的 User-Thread 切换已经基本达到一样的性能。
4. 抢占式调度和协作式调度的核心区别不是有新任务时是谁在执行，而是谁发出切换信号：抢占式调度往往在一些重要位置（ sleep call ，timer tick ）放置了中断信号，通过这个信号通知 scheduler 进行切换；协作式调度则是通过 thread 自己根据执行情况，主动交出控制权。