python os.fork子进程ID不连续

我正在使用CPython 3.7.2尝试

os.fork

函数 这是一个例子

def main():
    data = 222

    childPid = os.fork()
    if childPid == -1:
        print('error on fork child')
    elif childPid == 0:
        data *= 3
    else:
        time.sleep(3)

    print("PID=%d data=%d" % (os.getpid(), data))

当我使用C语言时，我总是得到父母和孩子的2个连续PID。 然而在python中，我总是得到不连续的PID（例如这里我得到了

21475

和

21442

）

---

不明白它是如何表现的不一样。

PID不能保证是连续的，尽管它们通常是连续的（在Linux上）。如果PID已在使用中，将跳过它

---

如果您在测试C代码时看到连续的PID，那是因为您碰巧没有遇到正在使用的PID。C中的

fork（）

和Python中的

os.fork（）

在行为上应该没有区别。

这有什么关系呢？只是好奇，因为它是CPython，如果我们在低级别使用相同的系统调用，操作系统通常会为我从书中读到的子系统分配下一个免费PID，所以我想知道为什么它们的行为不一样——在任何语言中都不能保证是连续的——在C语言中也不能。编写依赖于行为的代码是一条痛苦和痛苦的道路，而这些行为不是有文档记录的保证；同样地，在这些观察的基础上建立你的心智模型。我投票以离题结束这个问题，因为堆栈溢出要求问题，这是一个令人好奇的问题：手边的行为是明确而有意的实现定义的，并且随时可能因为任何原因或根本没有任何原因而改变。是的，这是同一个系统调用，但在C语言中，线程被抢占的可能性较小，同时创建另一个进程。但是，在许多情况下，PID不会是连续的（例如，现有PID已经存在，并且序列中的下一个PID值也存在）。在这种情况下，内核将使用序列中的下一个可用值创建一个PID。在分叉过程时，不应期望PID是连续的。唯一的保证是所有的PID都是唯一的（从来没有两个PID给定相同的数字）。您所描述的对于Linux是准确的，但对于某些BSD却不准确。我很好奇为什么我使用python时下一个可用的

总是不连续的，看起来有100%的几率。我的工作系统并不是用busyUse
strace
或
sysdig
之类的东西来查看实际的系统调用。如果运行时所做的工作存在任何实际差异，那么它必然会在系统调用层公开。由于
sysdig
为您提供了任何时间点上所有进程的完整系统视图，其日志包括跟踪在每个
fork（）
时使用的PID。Jonathon Reinhart——这一点很好。这是一个需要了解的重要细节。
PID=21475 data=666
PID=21442 data=222