Skip to content

Archive

Parallelism

3 articles
Python 09 Sep 2026 10 min read

Run CPU-Bound Python with InterpreterPoolExecutor

For CPU-heavy Python work, I usually reach for ProcessPoolExecutor. Threads are convenient, but ordinary CPython threads do not give CPU-bound Python code the kind of multi-core parallelism people often expect. Python 3.14 adds another option: concurrent.futures.InterpreterPoolExecutor. It looks deliberately familiar. You still submit callables and receive futures, but every worker thread owns a separate Python interpreter. Each interpreter has its own GIL, so Python code in different workers can execute on different CPU cores at the same time.

Python 09 Sep 2026 11 min read

Manage Subinterpreters Directly with Python 3.14

Python 3.14 gives application code a new way to work directly with multiple interpreters in one process. The concurrent.interpreters module exposes a high-level API for creating interpreters, running code inside them, and communicating through cross-interpreter queues. It sits below InterpreterPoolExecutor: instead of submitting independent jobs to a ready-made pool, you own the interpreter lifecycle and decide how work reaches each isolated execution context. That extra control is useful, but it also removes several conveniences an executor normally provides. A subinterpreter is not a lightweight thread with shared globals, and creating one does not automatically create concurrency.

Python 08 Sep 2026 11 min read

Run CPU-Bound Python Work with InterpreterPoolExecutor

Python has traditionally offered two familiar high-level choices for parallel work: threads and processes. Python 3.14 adds a third option to concurrent.futures: InterpreterPoolExecutor. It runs workers in separate Python interpreters inside one process. Each worker has its own interpreter state and its own Global Interpreter Lock (GIL), so pure Python code can execute on multiple CPU cores at the same time. That makes the executor interesting for CPU-bound workloads, but it is not a drop-in way to make arbitrary threaded code parallel. Interpreter isolation changes the programming model. Mutable Python objects are not simply shared between workers, submitted work crosses a serialization boundary, imports and module globals are interpreter-local, and extension compatibility deserves deliberate testing.