Skip to content

Support isolated sub-interpreters in Python 3.10 build #92

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
polkovnikov opened this issue Sep 29, 2021 · 4 comments
Closed

Support isolated sub-interpreters in Python 3.10 build #92

polkovnikov opened this issue Sep 29, 2021 · 4 comments
Labels
compatibility Compatibility with CPython and the broader ecosystem

Comments

@polkovnikov
Copy link
Contributor

polkovnikov commented Sep 29, 2021

Feature Request

In Python 3.10 ./configure you can pass option --with-experimental-isolated-subinterpreters (this just does #define EXPERIMENTAL_ISOLATED_SUBINTERPRETERS 1) which enables experimental feature of isolated interpreters, which allows to run multiple interpreters within separate Threads. There will be no GIL (global interpreter lock) anymore, each interpreter will have its separate Local interpreter lock.

This features allows to do within threads (single process) what multiprocessing module allowed to do between processes. Basically to use efficiently all cores of your CPU you don't need anymore to spawn separate processes, now you can spawn just threads within single process.

I think right now this feature can't be used within Python scripts code. Probably for now it is only available through Python C API. Meaning that only C/C++ applications can benefit from it right now. But I might be wrong. Also it should be available within Python scripts later as some special module/library probably in Python 3.11, when this feature becomes non-experimental.

For your python builds it would be great if this feature will be available as some configurable option (either within config file or some command-line option). Of course right now it shouldn't be enabled by default.

If you don't use ./configure (from Python sources) to build your scripts, then you just have to define
#define EXPERIMENTAL_ISOLATED_SUBINTERPRETERS 1
when compiling all .c files of Python. This feature spans many .c files so you have to do this define globally. Nothing else needed besides this define (as far as I can see when reading ./configure).

As far as I know implementing this feature needed to fix around 1500 places in the code. Mostly it needed making all global variables as thread local. And this thread local state is allocated separately for each interpreter's thread.

Don't know right now how Python objects are shared between these sub-interpreters, maybe only through serialization (marshaling), i.e. when converted to bytes. Or maybe they can be shared as read-only (if nothing mutates them at this moment). Have to investigate all the details, for that a good build of Python is needed to experiment.

@polkovnikov
Copy link
Contributor Author

@indygreg

Feature request above suggests to incorporate support for isolated sub-interpreters. This is experimental feature, which should be enabled separately, it is done through

./configure --with-experimental-isolated-subinterpreters

when compiling CPython. Or by passing #define EXPERIMENTAL_ISOLATED_SUBINTERPRETERS 1 when doing same compilation.

My question is how to pass both these ways to build script? When I call python-build-standalone/cpython-windows/build.py can I pass these flags somehow?

I'm interested in question how can I re-build CPython using your tools so that this feature is enabled?

@indygreg
Copy link
Collaborator

This project simply invokes CPython's configure inside cpython-unix/build-cpython.sh. So if you want to pass --with-experimental-isolated-subinterpreters, you can modify the script locally to add that argument.

As for Windows, you likely need to modify a Visual Studio project file to pass the define to the preprocessor.

Since the sub-interpreters feature isn't stable and requires a build-time option, it's likely not something I'm interested in adding official support for at this time. However, I could see the benefit of a generic mechanism to pass additional configure flags to CPython's build system to make things like this easier.

@polkovnikov
Copy link
Contributor Author

@indygreg Yes, if it is not too difficult, it would be great to add both kinds of options:

  1. So that it is possible to do python build.py --configure-flag=--with-experimental-isolated-subinterpreters=123.

  2. And also possible to do python build.py --preprocessor-define=EXPERIMENTAL_ISOLATED_SUBINTERPRETERS=1.

It is great to have both. But probably configure 1) is possible only for Unix, but define 2) should be available in both Unix and Windows.

BTW, have you used this feature at all in your practice or read about it? Would be great if you share knowledge/code about how to use it.

@charliermarsh charliermarsh added the compatibility Compatibility with CPython and the broader ecosystem label Dec 18, 2024
@geofft
Copy link
Collaborator

geofft commented Jan 29, 2025

The subinterpreter support is on by default (no longer experimental) starting with 3.13, and the low level _interpreters standard library module seems to be included in our 3.13 and 3.14a0 releases. I believe the way you're supposed to use it is to install https://pypi.org/project/interpreters-pep-734/ (with pip/uv/etc.) and do from interpreters_backport import interpreters, until such time as that stabilizes enough to end up in the standard library as plain import interpreters.

I'm going to close this since the direct request is solved. I do like the idea of adding a command-line option for additional flags though.

@geofft geofft closed this as completed Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with CPython and the broader ecosystem
Projects
None yet
Development

No branches or pull requests

4 participants