Linux 进程创建机制面临重构
值得看指数 72.0 NO. 013 · 2026.06.07
发布2026/06/06Score185Comments178
为什么值得看
Linux 内核社区正讨论用更现代的 API 替代沿用 50 年的 fork()+exec() 组合，以解决多线程程序中的安全性和性能隐患。对 AI 基础设施开发者而言，这直接影响容器运行时、模型推理服务进程管理等核心场景的底层实现。
媒体预览
编辑判断
fork() 在 AI 工程里的隐患被严重低估。多线程推理服务中，某个线程持有 CUDA context 时 fork() 会触发死锁或静默数据损坏，这是 PyTorch、TensorFlow 生产环境偶发崩溃的隐藏根因之一。社区主推的 posix_spawn 和 Linux 特有的 clone3 是替代方向，但迁移成本在于大量现有代码依赖 fork() 的 COW 语义做内存隔离。
做模型 serving 框架或自研推理引擎的团队，现在就该审计代码里的 fork 调用点，特别是多卡并行场景下的子进程创建逻辑。容器运行时开发者更要关注，runc、crun 这些底层工具对 fork 的依赖很深，内核 API 变迁会倒逼整个链路重构。
社区反馈
意见分歧 139 条评论
核心争论：fork()替代方案需暴露原生API而非简单封装，共享库内存共享机制被误解
I'm not surprised Chen's patch was rejected; that's an extremely niche usecase not worth supporting. With my shell developer hat on, I agree with the closing "developers would likely welcome a native implementation that isn't (unlike the current implementation) hiding fork() and exec() under the cov
It sounds like they're interested in the concept though, just not that specific implementation.
Yeah this seems like a promising discussion.