文章讨论了Unix传统的fork()+exec()进程创建模型的优缺点。虽然这种模型优雅简洁，但fork()需要复制整个进程状态，开销较大，且常紧随exec()调用导致资源浪费。Linux内核已进行优化，但根本问题仍存。最新提出的"spawn templates"方案虽未被采纳，但可能为未来新的进程创建机制指明方向。

标题：超越fork()+exec()：探索Linux进程创建新范式

核心内容： 1. 历史背景 - Unix传统进程创建模型依赖fork()和exec()系统调用 - Linux内核中对应实现为clone()和execve() - 该模型存在固有缺陷：fork()需完整复制父进程状态（包括内存），而随后的exec()又会丢弃这些复制内容

2. 现有优化尝试

• vfork()等优化方案效果有限
• 主要问题在于fork()操作本质上的高成本性

3. 新提案分析 李晨提出的"spawn模板"方案：

• 针对重复执行相同可执行文件场景（如频繁调用Git）
• 通过spawntemplatecreate()系统调用创建模板
• 使用spawntemplatespawn()快速生成新进程
• 基准测试显示约2%的性能提升

4. 技术社区反馈

• Mateusz Guzik指出应聚焦fork()替代方案
• Christian Brauner建议基于pidfd抽象构建新API
• 共识方向：实现原生的posix_spawn()支持

5. 未来方向

• 放弃当前spawn模板方案
• 转向构建支持posix_spawn()的新进程创建原语
• 目标实现无需隐藏fork()/exec()的本地化实现

（注：删减了具体结构体字段细节、部分技术讨论的往返过程等次要内容，保留了核心技术思路和发展方向的关键信息）

评论观点总结：

1. 支持fork()的现有设计

• 认为fork()+exec()模型优雅灵活，能进行各种配置（uecker） "The elegance of the fork() + exec() model is that every kind of configuration can be done after the fork using all the usual APIs."
• 指出copy-on-write优化已解决内存复制问题（mrkeen） "the optimisation that means that you don't copy over all the memory."

2. 批评fork()的局限性

• 认为fork()是过时的设计，应该被淘汰（rom1v引用论文） "fork was a clever hack... that has long outlived its usefulness and is now a liability"
• 指出Windows的CreateProcessW是更好的设计（Panzerschrek） "Windows does this better with its CreateProcessW interface"

3. 关于性能的讨论

• 强调fork()实际上是O(N)复杂度（jcalvinowens） "it is O(N) on the size of the process, and it always has been"
• 认为频繁创建大进程本身就是错误做法（burnt-resistor） "If you are repeatedly creating large processes, you are already doing it wrong"

4. 替代方案建议

• 建议将核心功能做成库而非二进制（lokar） "the core of git should be a library you can link"
• 提出类似schedextops的可扩展方案（debatem1） "built the rough flow chart of a combined fork-exec, but with hooks"

5. 相关技术讨论

• 质疑多进程重复加载相同库的问题（hparadiz） "every linux process has the same libgcc_so.so.1 loaded into memory"
• 讨论fork后环境复制的问题（Sophira） "each new process needs a copy of the parent process' environment"