Python has another local parallelization library—thread. The thread objects it provides are created and used in much the same way that multiprocessing.Process objects are, but thread-based processes run in the same memory space as the parent process, while Process objects, when they are started, actually create a new Python interpreter instance (with some connection capabilities to the parent Python interpreter).

Because threads run in the same interpreter and memory space, they are not capable of accessing multiple processors the same way that a Process can.

Thread-based parallelization is also far more likely to encounter conflicts with Python's global interpreter lock (GIL). The GIL actively prevents multiple threads from executing or altering the same Python bytecode at the same time. There are some potentially long-running processes that happen outside the GIL's control—I/O, networking, some image processing functionality, and various libraries such as NumPy—but outside those exceptions, any multithreaded Python program that spends a lot of its execution time interpreting or manipulating Python bytecode will eventually hit a GIL bottleneck, losing its parallelization in the process.