mod_wsgi 6.0.0 (currently in release candidate) introduces the WSGIPerInterpreterGIL directive, enabling sub-interpreters to hold their own GIL per PEP 684 (Python 3.12+). This allows parallel Python bytecode execution across sub-interpreters within a single process, without requiring additional daemon processes. The feature is opt-in and builds on mod_wsgi's existing application group/sub-interpreter isolation model. Key limitations include: the main interpreter is excluded, C extensions must use PEP 489 multi-phase init and declare Py_MOD_PER_INTERPRETER_GIL_SUPPORTED, daemon threads are disallowed in sub-interpreters with their own GIL, and each sub-interpreter independently imports the application (increasing memory). The directive is most beneficial for CPU-bound workloads that can be partitioned across sub-interpreters; I/O-bound apps see minimal gain. A companion WSGIFreeThreading directive for free-threaded Python builds will be covered in a follow-up post.
Table of contents
Why the GIL has always been the deployment problemWhat changed in Python 3.12 and 3.14How mod_wsgi has always used sub-interpretersThe new directiveComposing with daemon modeWhich applications actually benefitThe gotchasWhat this means for C extension authorsWhat's nextSort: