The GIL

The GIL protects concurrent access to most of CPython’s runtime state. So all that GIL-protected global state must move to each interpreter before the GIL can.

(In a handful of cases, other mechanisms can be used to ensure thread-safe sharing instead, such as locks or “immortal” objects.)

CPython Runtime State

Properly isolating interpreters requires that most of CPython’s runtime state be stored in the PyInterpreterState struct. Currently, only a portion of it is; the rest is found either in global variables or in _PyRuntimeState. Most of that will have to be moved.

This directly coincides with an ongoing effort (of many years) to greatly reduce internal use of C global variables and consolidate the runtime state into _PyRuntimeState and PyInterpreterState. (See Consolidating Runtime Global State below.) That project has significant merit on its own and has faced little controversy. So, while a per-interpreter GIL relies on the completion of that effort, that project should not be considered a part of this proposal–only a dependency.

Other Isolation Considerations

CPython’s interpreters must be strictly isolated from each other, with few exceptions. To a large extent they already are. Each interpreter has its own copy of all modules, classes, functions, and variables. The CPython C-API docs explain further.

However, aside from what has already been mentioned (e.g. the GIL), there are a couple of ways in which interpreters still share some state.

First of all, some process-global resources (e.g. memory, file descriptors, environment variables) are shared. There are no plans to change this.

Second, some isolation is faulty due to bugs or implementations that did not take multiple interpreters into account. This includes CPython’s runtime and the stdlib, as well as extension modules that rely on global variables. Bugs should be opened in these cases, as some already have been.

Depending on Immortal Objects

PEP 683 introduces immortal objects as a CPython-internal feature. With immortal objects, we can share any otherwise immutable global objects between all interpreters. Consequently, this PEP does not need to address how to deal with the various objects exposed in the public C-API. It also simplifies the question of what to do about the builtin static types. (See Global Objects below.)

Both issues have alternate solutions, but everything is simpler with immortal objects. If PEP 683 is not accepted then this one will be updated with the alternatives. This lets us reduce noise in this proposal.

Indirect Benefits

Most of the effort needed for a per-interpreter GIL has benefits that make those tasks worth doing anyway:

• makes multiple-interpreter behavior more reliable
• has led to fixes for long-standing runtime bugs that otherwise hadn’t been prioritized
• has been exposing (and inspiring fixes for) previously unknown runtime bugs
• has driven cleaner runtime initialization (PEP 432, PEP 587)
• has driven cleaner and more complete runtime finalization
• led to structural layering of the C-API (e.g. Include/internal)
• also see Benefits to Consolidation below

Furthermore, much of that work benefits other CPython-related projects:

• performance improvements (“faster-cpython”)
• pre-fork application deployment (e.g. Instagram)
• extension module isolation (see PEP 630, etc.)
• embedding CPython

Existing Use of Multiple Interpreters

The C-API for multiple interpreters has been used for many years. However, until relatively recently the feature wasn’t widely known, nor extensively used (with the exception of mod_wsgi).

In the last few years use of multiple interpreters has been increasing. Here are some of the public projects using the feature currently:

• mod_wsgi
• OpenStack Ceph
• JEP
• Kodi

Note that, with PEP 554, multiple interpreter usage would likely grow significantly (via Python code rather than the C-API).

PEP 554

PEP 554 is strictly about providing a minimal stdlib module to give users access to multiple interpreters from Python code. In fact, it specifically avoids proposing any changes related to the GIL. Consider, however, that users of that module would benefit from a per-interpreter GIL, which makes PEP 554 more appealing.

Per-Interpreter State

The following runtime state will be moved to PyInterpreterState:

• all global objects that are not safely shareable (fully immutable)
• the GIL
• mutable, currently protected by the GIL
• mutable, currently protected by some other per-interpreter lock
• mutable, may be used independently in different interpreters
• all other mutable (or effectively mutable) state not otherwise excluded below

Furthermore, a number of parts of the global state have already been moved to the interpreter, such as GC, warnings, and atexit hooks.

The following state will not be moved:

• global objects that are safely shareable, if any
• immutable, often const
• treated as immutable
• related to CPython’s main() execution
• related to the REPL
• set during runtime init, then treated as immutable
• mutable, protected by some global lock
• mutable, atomic

Note that currently the allocators (see Objects/obmalloc.c) are shared between all interpreters, protected by the GIL. They will need to move to each interpreter (or a global lock will be needed). This is the highest risk part of the work to isolate interpreters and may require more than just moving fields down from _PyRuntimeState. Some of the complexity is reduced if CPython switches to a thread-safe allocator like mimalloc.

C-API

The following private API will be made public:

• _PyInterpreterConfig
• _Py_NewInterpreter() (as Py_NewInterpreterEx())

The following fields will be added to PyInterpreterConfig:

• own_gil - (bool) create a new interpreter lock (instead of sharing with the main interpreter)
• strict_extensions - fail import in this interpreter for incompatible extensions (see Restricting Extension Modules)

Restricting Extension Modules

Extension modules have many of the same problems as the runtime when state is stored in global variables. PEP 630 covers all the details of what extensions must do to support isolation, and thus safely run in multiple interpreters at once. This includes dealing with their globals.

Extension modules that do not implement isolation will only run in the main interpreter. In all other interpreters, the import will raise ImportError. This will be done through importlib._bootstrap_external.ExtensionFileLoader.

We will work with popular extensions to help them support use in multiple interpreters. This may involve adding to CPython’s public C-API, which we will address on a case-by-case basis.

Documentation

The “Sub-interpreter support” section of Doc/c-api/init.rst will be updated with the added API.

Backwards Compatibility

No behavior or APIs are intended to change due to this proposal, with one exception noted in the next section. The existing C-API for managing interpreters will preserve its current behavior, with new behavior exposed through new API. No other API or runtime behavior is meant to change, including compatibility with the stable ABI.

See Objects Exposed in the C-API below for related discussion.

Extension Module Maintainers

One related consideration is that a per-interpreter GIL will likely drive increased use of multiple interpreters, particularly if PEP 554 is accepted. Some maintainers of large extension modules have expressed concern about the increased burden they anticipate due to increased use of multiple interpreters.

Specifically, enabling support for multiple interpreters will require substantial work for some extension modules. To add that support, the maintainer(s) of such a module (often volunteers) would have to set aside their normal priorities and interests to focus on compatibility (see PEP 630).

Of course, extension maintainers are free to not add support for use in multiple interpreters. However, users will increasingly demand such support, especially if the feature grows in popularity.

Either way, the situation can be stressful for maintainers of such extensions, particularly when they are doing the work in their spare time. The concerns they have expressed are understandable, and we address the partial solution in Restricting Extension Modules below.

Alternate Python Implementations

Other Python implementation are not required to provide support for multiple interpreters in the same process (though some do already).

Security Implications

There is no known impact to security with this proposal.

Maintainability

On the one hand, this proposal has already motivated a number of improvements that make CPython more maintainable. That is expected to continue. On the other hand, the underlying work has already exposed various pre-existing defects in the runtime that have had to be fixed. That is also expected to continue as multiple interpreters receive more use. Otherwise, there shouldn’t be a significant impact on maintainability, so the net effect should be positive.

Performance

The work to consolidate globals has already provided a number of improvements to CPython’s performance, both speeding it up and using less memory, and this should continue. Performance benefits to a per-interpreter GIL have not been explored. At the very least, it is not expected to make CPython slower (as long as interpreters are sufficiently isolated).

Sharing Global Objects

We are sharing some global objects between interpreters. This is an implementation detail and relates more to globals consolidation than to this proposal, but it is a significant enough detail to explain here.

The alternative is to share no objects between interpreters, ever. To accomplish that, we’d have to sort out the fate of all our static types, as well as deal with compatibility issues for the many objects exposed in the public C-API.

That approach introduces a meaningful amount of extra complexity and higher risk, though prototyping has demonstrated valid solutions. Also, it would likely result in a performance penalty.

Immortal objects allow us to share the otherwise immutable global objects. That way we avoid the extra costs.

Consolidating Runtime Global State

As noted in CPython Runtime State above, there is an active effort (separate from this PEP) to consolidate CPython’s global state into the _PyRuntimeState struct. Nearly all the work involves moving that state from global variables. The project is particularly relevant to this proposal, so below is some extra detail.

./python Tools/c-analyzer/table-file.py Tools/c-analyzer/cpython/globals-to-fix.tsv