`posix_spawn` 的能力

Question

我正在编写一个小程序，它有点像一个服务器，它产生它的客户端程序（在本地，而不是通过网络）并在它们之间做一些有趣的事情。虽然我使用的主要操作系统是 Linux，但我希望它可以在包括 Windows 在内的其他操作系统上运行。有fork 和exec 可以完成这项工作，但是当我通过cygwin 将程序移植到Windows 时，我不希望在cygwin 中实现的那个糟糕的fork 启动，它实际上调用CreateProcess 并复制当前进程的内存区域使用setjmp/longjmp 和共享内存互斥锁到新进程，所有这些都是为了替换为另一个程序（exec）。在阅读 cygwin 的 FAQ 页面时，我发现了 spawn.h 和它的 posix_spawn，在 Windows 中基本上看起来像 CreatePorcess(Ex)。这似乎是一个新功能（......我的意思不是原始 UNIX 系统功能之一），所以我有一些问题。

1. 它实施得好、广泛吗？ （我在网上看到一些帖子，没有在他/她的系统下定义。）

2. 在 Linux 中使用 posix_spawn 代替 fork/exec 是否可以预期性能会有所提高或下降？

3. 为什么 posix_spawn 比 fork/exec 鲜为人知且使用率低，尽管自 1999 年以来就成为标准？

Answer 1

1. 它实施得好、广泛吗？ （我在网上看到一些帖子，没有在他/她的系统下定义。）

高级实时 XSI 选项组是可选的，因此您可以符合 POSIX，但不实施它。但是对于 GNU/Linux，您可以指望它现在可用。

1. 在 Linux 中使用 posix_spawn 而不是 fork/exec 可以预期任何性能改进或下降吗？

可能是的，对于大型进程，quite some time 可以用于复制页表，但在exec 时间被丢弃。 posix_spawn 的实现（如 musl 或 glibc）尽可能使用 vfork(2)（或直接使用 clone(2)）以避免这种情况。对于像 cygwin 这样的系统，fork 是 emulated，成本相当高，posix_spawn 大大降低了开销。

1. 为什么 posix_spawn 虽然自 1999 年就成为标准，但与 fork/exec 相比知名度和使用率更低？

我猜是惯性。

Answer 2

根据Linux man pages，它出现在 2000 年发布的 glibc 版本 2.2 中，并且该实现符合 POSIX.1-2001 和 POSIX.1-2008。我希望它至少能在至少使用这个 glibc 版本的任何平台上得到支持，因为它的行为至少可以在这些平台上用 fork + exec 模拟。

在 Linux 上，如果使用 vfork 而不是 fork，您可能会期望比 fork/exec 略有性能改进：

当满足以下任一条件时，使用 vfork(2) 而不是 fork(2) 创建子进程：

• attrp 指向的属性对象的 spawn-flags 元素包含 GNU 特定的标志 POSIX_SPAWN_USEVFORK；或
• file_actions 为 NULL，attrp 指向的属性对象的 spawn-flags 元素不包含 POSIX_SPAWN_SETSIGMASK、POSIX_SPAWN_SETSIGDEF、POSIX_SPAWN_SETSCHEDPARAM、 POSIX_SPAWN_SETSCHEDULER、POSIX_SPAWN_SETPGROUP 或 POSIX_SPAWN_RESETIDS。

换句话说，如果调用者请求 vfork(2)，或者如果子进程在 exec(3)s 请求的文件之前没有预期的清理，则使用 vfork(2)。

Answer 3

posix_spawn没有广泛实施，但无论如何你都应该使用它。

• 如果平台缺少它，使用只执行 fork-and-exec 的插入式替换总是很容易。

• 如果“本机”/最佳实现可用（作为系统的一部分，或作为平台特定的嵌入式实现），它将对 fork 昂贵的系统产生很大影响，对于根本无法执行 fork 的系统（无 MMU 的系统、没有 cygwin 之类的 Windows 等），差异更大。

1234563 .有关一些发现，请参阅此 Twitter 线程：https://twitter.com/RichFelker/status/602313644026761216

至于为什么它没有被更广泛地使用/实现，它可能是由于不广为人知，以及相当笨拙、无缘无故的面向对象的 API 设计。