Skip to content
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

Implement PEP 684: A Per-Interpreter GIL #99113

Open
ericsnowcurrently opened this issue Nov 5, 2022 · 1 comment
Open

Implement PEP 684: A Per-Interpreter GIL #99113

ericsnowcurrently opened this issue Nov 5, 2022 · 1 comment
Labels
3.12 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-subinterpreters type-feature A feature request or enhancement

Comments

@ericsnowcurrently
Copy link
Member

ericsnowcurrently commented Nov 5, 2022

While PEP 684 is not accepted yet (and could get rejected, of course), it would be helpful to have an issue against which I can start creating draft PRs for the implementation.

This issue isn't for all the prerequisite work for a per-interpreter GIL, rather just the implementation of what's actually specified in the PEP. The rest is happening separately.

(Also see my checklist: https://github.com/ericsnowcurrently/multi-core-python/wiki/0-The-Plan)

@ericsnowcurrently ericsnowcurrently added type-feature A feature request or enhancement interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-subinterpreters 3.12 new features, bugs and security fixes labels Nov 5, 2022
ericsnowcurrently added a commit that referenced this issue May 5, 2023
In preparation for a per-interpreter GIL, we add PyInterpreterState.ceval.gil, set it to the shared GIL for each interpreter, and use that rather than using _PyRuntime.ceval.gil directly.  Note that _PyRuntime.ceval.gil is still the actual GIL.
@ericsnowcurrently
Copy link
Member Author

Docs updates:

ericsnowcurrently added a commit that referenced this issue May 5, 2023
Here we are doing no more than adding the value for Py_mod_multiple_interpreters and using it for stdlib modules.  We will start checking for it in gh-104206 (once PyInterpreterState.ceval.own_gil is added in gh-104204).
ericsnowcurrently added a commit that referenced this issue May 5, 2023
We also add PyInterpreterState.ceval.own_gil to record if the interpreter actually has its own GIL.

Note that for now we don't actually respect own_gil; all interpreters still share the one GIL.  However, PyInterpreterState.ceval.own_gil does reflect PyInterpreterConfig.own_gil.  That lie is a temporary one that we will fix when the GIL really becomes per-interpreter.
carljm added a commit to carljm/cpython that referenced this issue May 5, 2023
* main:
  pythongh-99113: Add PyInterpreterConfig.own_gil (pythongh-104204)
  pythongh-104146: Remove unused var 'parser_body_declarations' from clinic.py (python#104214)
  pythongh-99113: Add Py_MOD_PER_INTERPRETER_GIL_SUPPORTED (pythongh-104205)
  pythongh-104108: Add the Py_mod_multiple_interpreters Module Def Slot (pythongh-104148)
  pythongh-99113: Share the GIL via PyInterpreterState.ceval.gil (pythongh-104203)
  pythonGH-100479: Add `pathlib.PurePath.with_segments()` (pythonGH-103975)
  pythongh-69152: Add _proxy_response_headers attribute to HTTPConnection (python#26152)
  pythongh-103533: Use PEP 669 APIs for cprofile (pythonGH-103534)
  pythonGH-96803: Add three C-API functions to make _PyInterpreterFrame less opaque for users of PEP 523. (pythonGH-96849)
ericsnowcurrently added a commit that referenced this issue May 6, 2023
…4206)

Py_MOD_PER_INTERPRETER_GIL_SUPPORTED is a new supported value for Py_mod_multiple_interpreters, added in gh-104205.
ericsnowcurrently added a commit that referenced this issue May 6, 2023
This is a pre-requisite for a per-interpreter GIL.  Without it this change isn't strictly necessary.  However, there is no real downside otherwise.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.12 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-subinterpreters type-feature A feature request or enhancement
Projects
Status: No status
Development

No branches or pull requests

1 participant