是Python吗os.fork操作系统使用相同的python解释器？

Question

我知道Python中的线程使用相同的Python解释器实例。我的问题是由os.fork创建的进程也是这样吗？或者os.fork创建的每个进程都有自己的解释器吗？在

Answer 1

os.fork()相当于许多UNIC中的fork()系统调用。因此，是的您的子进程将与父进程分离，并有一个不同的解释器（，因此）。在

^{}：

FORK(2)

NAME fork - create a child process

SYNOPSIS #include

   pid_t fork(void);

DESCRIPTION fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points:

^{}：

os.fork() Fork a child process. Return 0 in the child and the child’s process id in the parent. If an error occurs OSError is raised.

Note that some platforms including FreeBSD <= 6.3, Cygwin and OS/2 EMX have known issues when using fork() from a thread.

另见：Martin Konecny对“分叉”的原因和优势的回应：

为简洁起见，其他不涉及单独进程的并发方法，因此也不涉及单独的Python解释器，包括：

• 绿色或轻量级线程；alagreenlet
• 协同程序ala Python生成器和新的python3+^{}
• 异步I/O alaasyncio、Twisted、circuits等

Answer 2

虽然fork确实创建了当前Python解释器的副本，而不是使用同一个解释器运行，但它通常不是您想要的，至少它本身不是。在其他问题中：

• 在某些平台上分叉多线程进程可能会出现问题。一些库（最著名的是苹果的Cocoa/CoreFoundation）可能会在后台为您启动线程，或者在您不知情的情况下使用线程本地api，等等。在
• 有些库假定每个进程都将正确初始化，但如果在初始化之后fork，则这不是真的。最臭名昭著的是，如果您让ssl在主进程中播种它的PRNG，然后fork，那么现在就有了潜在的可预测随机数，这对您的安全性是一个很大的漏洞。在
• 打开的文件描述符由子系统继承（作为dup），在不同的平台上，细节会以令人讨厌的方式变化。在
• POSIX只需要平台来实现fork和exec之间的一组非常具体的系统调用。如果从未调用exec，则只能使用这些系统调用。这基本上意味着你不能做任何可移植的事情。在
• 与信号有关的任何事情都是特别是烦人和不可移植的fork。在

有关这些问题的详细信息，请参见POSIX ^{}或平台的手册页。在

正确的答案几乎总是使用^{}，或^{}（它包含multiprocessing）或类似的第三方库。

在3.4+中，您甚至可以指定一个start method。fork方法基本上只调用fork。forkserver方法运行一个“干净”进程（没有线程、信号处理程序、SSL初始化等），并从中派生出新的子进程。spawn方法调用fork，然后调用exec，或者类似posix_spawn的等效方法，以获得一个全新的解释器而不是副本。因此，您可以从fork开始，但是如果有任何问题，请切换到forkserver或{}，代码中的其他内容都不必更改。很不错。在

Answer 3

每当您fork时，整个Python进程都会在内存中复制（包括Python解释器、代码和任何库、当前堆栈等），以创建第二个进程—这也是为什么分叉一个进程比创建一个线程要贵得多的原因之一。在

这将创建python解释器的新副本。在

运行两个python解释器的一个优点是现在有两个GIL（全局解释器锁），因此可以在多核系统上实现真正的多处理。在

一个进程中的线程共享相同的GIL，这意味着在给定的时刻只有一个线程运行，只会产生并行的错觉。在