I understand that threads in Python use the same instance of Python interpreter. My question is it the same with process created by os.fork
? Or does each process cr
While fork
does indeed create a copy of the current Python interpreter rather than running with the same one, it usually isn't what you want, at least not on its own. Among other problems:
fork
after initialization that isn't true. Most infamously, if you let ssl
seed its PRNG in the main process, then fork, you now have potentially predictable random numbers, which is a big hole in your security.fork
and an exec
. If you never call exec
, you can only use those syscalls. Which basically means you can't do anything portably.fork
.See POSIX fork or your platform's manpage for details on these issues.
The right answer is almost always to use multiprocessing, or concurrent.futures (which wraps up multiprocessing
), or a similar third-party library.
With 3.4+, you can even specify a start method. The fork
method basically just calls fork
. The forkserver
method runs a single "clean" process (no threads, signal handlers, SSL initialization, etc.) and forks off new children from that. The spawn
method calls fork
then exec
, or an equivalent like posix_spawn
, to get you a brand-new interpreter instead of a copy. So you can start off with fork
, ut then if there are any problems, switch to forkserver
or spawn
and nothing else in your code has to change. Which is pretty nice.