为什么更新的glibc用vfork而不是posix_spawn来实现？

Question

我正在用glibc 2.17和glibc 2.27跟踪posix_spawn源代码。

(glibc 2.17: sysdeps/posix/spawni.c)

(glibc 2.27: sysdeps/unix/sysv/linux/spawni.c)

我发现glibc2.17根据标志和文件操作使用v叉或fork。

我想这是由于多线程安全或比赛的情况。

但是在glibc 2.27中，它只使用vfork创建子进程。

为什么glibc会改变实现？

更新的linux内核是否能更好地防止争用条件的出现？

Answer 1

对于大型进程，vfork的效率要比fork高得多，因为地址空间根本不需要重复。最初，人们担心适当的取消处理将需要在文件操作出现时使用fork，但最终确定当前的vfork-based实现是足够的。

在qemu用户和微软的模拟中，vfork仍然是失效的，但是在使用posix_spawn时通常看不到but，因为它实际上并不使用vfork，而是使用带有单独堆栈的vfork-style clone系统调用，因此即使父进程没有正确暂停，子进程中的堆栈也不会受到破坏。

有背景资料的一些资源：

• 在比现在更多的情况下，spawn应该使用vfork()
• posix:清理 (加上后续的审查线程)
• 生成{p}实现 (同样)
• glibc "linux: spawni.c:简化对父级的错误报告“ (关于暴露vfork仿真错误的断言的讨论)
• Windows仿真v叉错误 (同样)