Devsolved
The Symptom
Symptom
We implemented a new endpoint to apply filters to uploaded images. To make it faster, a developer used Python's `concurrent.futures.ThreadPoolExecutor` to process 4 image channels concurrently. Instead of being 4x faster, CPU utilization stayed stuck at 100% on a single core, and eventually, the Gunicorn workers hung entirely.
Root Cause Analysis
Root Cause
Python's Global Interpreter Lock (GIL) prevents multiple native threads from executing Python bytecodes at once. While `threading` works great for I/O-bound tasks (like making network requests), it completely blocks on CPU-bound tasks (like matrix math for image filters). The threads were thrashing violently as they fought for the GIL, adding massive context-switching overhead.
Code
python
import concurrent.futures
# The fatal flaw: Using threads for CPU-bound work in Python
with concurrent.futures.ThreadPoolExecutor(max_workers=4) as executor:
results = list(executor.map(heavy_cpu_image_filter, image_chunks))Resolution
Resolution
We switched from `ThreadPoolExecutor` to `ProcessPoolExecutor` (the `multiprocessing` module). This spins up entirely separate Python processes, each with its own GIL and memory space, allowing true parallelism across multiple CPU cores.
Discussions 0