发现一篇有趣的文章 Afork()in the road ,讲的是 fork api 设计的缺点
oaa · woodgear · 2020-08-02 21:04:53 +08:00 · 1758 次点击这是一个创建于 1356 天前的主题，其中的信息可能已经有所发展或是发生改变。
我的一点想法是 这是路径依赖的又一实例,fork 本来确实就蛮奇怪的,竟然是微软的人来发文章讲这件事,而不是 unix 社区自己的人来提出,真的是有点打脸.
什么叫大道至简,互相组合啊 --微软
后面的几个解决方案中spawn(实际就是 CreateProcess)看起来还有点意思.其他的几个感觉是修修补补.
不过我认为现在最大的问题在于进程这个概念是否要做出修正了.原本是自然而然的 process->thread 这条路 不过现在看起来要么显式的保留 proccess 这个概念,用协程走 golang 的路.要么是像 rust 走多线程事件驱动的路(这条路看来也只有 rust 能走 除非大家都上所有权这种能保证单一所有权的机制),不要用进程这种重的东西了,只保留区分不同程序这个语义就足够了.
引申起来有一个值得深思的问题是
如何保证向后兼容 或者讲如何最小化替换的成本和路径依赖
剪断耦合所有人走 kvm 的路是我所唯一能想到的
 |
1
vk42 2020-08-02 21:46:13 +08:00
关于 POSIX 那一套接口的合理性和效率讨论已经好多年了，glibc 现在默认也早不用 fork()了
|
Select Language