发现一篇有趣的文章 Afork()in the road ,讲的是 fork api 设计的缺点

[oaa]

A fork()in the road

我的一点想法是 这是路径依赖的又一实例,fork 本来确实就蛮奇怪的,竟然是微软的人来发文章讲这件事,而不是 unix 社区自己的人来提出,真的是有点打脸.

什么叫大道至简,互相组合啊 --微软

后面的几个解决方案中spawn(实际就是 CreateProcess)看起来还有点意思.其他的几个感觉是修修补补.

不过我认为现在最大的问题在于进程这个概念是否要做出修正了.原本是自然而然的 process->thread 这条路 不过现在看起来要么显式的保留 proccess 这个概念,用协程走 golang 的路.要么是像 rust 走多线程事件驱动的路(这条路看来也只有 rust 能走 除非大家都上所有权这种能保证单一所有权的机制),不要用进程这种重的东西了,只保留区分不同程序这个语义就足够了.

引申起来有一个值得深思的问题是

如何保证向后兼容 或者讲如何最小化替换的成本和路径依赖

剪断耦合所有人走 kvm 的路是我所唯一能想到的

[vk42]

关于 POSIX 那一套接口的合理性和效率讨论已经好多年了，glibc 现在默认也早不用 fork()了