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

Rename "own_gil" Field of PyInterpreterConfig to "gil" #105603

Closed
ericsnowcurrently opened this issue Jun 9, 2023 · 0 comments
Closed

Rename "own_gil" Field of PyInterpreterConfig to "gil" #105603

ericsnowcurrently opened this issue Jun 9, 2023 · 0 comments
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API topic-subinterpreters type-feature A feature request or enhancement

Comments

@ericsnowcurrently
Copy link
Member

ericsnowcurrently commented Jun 9, 2023

We've added the PyInterpreterConfig struct in 3.12. For PEP 684 (per-interpreter GIL), likewise 3.12, we added a new int-boolean field, "own_gil", to indicate if PyInterpreterState.ceval.gil should point to the interpreter's own GIL.

Having finally just read through PEP 703 (no-gil), I realized that it would probably be useful to change that field to support a number of different values, rather than just a binary situation. Consequently, I'm proposing we change the field as follows (more or less):

#define PyInterpreterConfig_SHARED_GIL 1  /* shared with main interpreter, so PyInterpreterConfig_MAIN_GIL? */
#define PyInterpreterConfig_OWN_GIL 2

typedef struct {
    ...
    int gil;
    ...
} PyInterpreterConfig;

That would give us more flexibility for other possible future scenarios (e.g. no-gil), where "own_gil" wouldn't make sense.


Changing this in 3.12, even though we're past feature freeze, would be good so we don't have to live with a deprecated field in the struct. I'd be surprised if anyone was really using PyInterpreterConfig yet, and the change will be very focused, so we should be okay to make this change so late in the game.

CC @Yhg1s

Linked PRs

@ericsnowcurrently ericsnowcurrently added type-feature A feature request or enhancement interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-subinterpreters topic-C-API 3.12 bugs and security fixes 3.13 new features, bugs and security fixes labels Jun 9, 2023
ericsnowcurrently added a commit that referenced this issue Jun 13, 2023
We are changing it to be more flexible that a strict bool can be for possible future expanded used cases.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 13, 2023
…gh-105620)

We are changing it to be more flexible that a strict bool can be for possible future expanded used cases.
(cherry picked from commit b97e14a)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
ericsnowcurrently added a commit that referenced this issue Jun 13, 2023
…5620) (gh-105731)

We are changing it to be more flexible that a strict bool can be for possible future expanded used cases.
(cherry picked from commit b97e14a)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API topic-subinterpreters type-feature A feature request or enhancement
Projects
Status: Done
Development

No branches or pull requests

1 participant