gh-119213: Fix getargs.c to store state in InterpreterState... by 1st1 · Pull Request #119195 · python/cpython
Conversation
...as opposed to storing it in PyRuntime. Storing it in PyRuntime
is fundametally wrong, as its state contains references to Python
objects. Those objects (tuples and strings) can (and will) be
picked by various subinterpreter clean up code, leaving PyRuntime
with broken pointers.
#119194 is a backport to 3.12
Fix getargs.c to store state in InterpreterState...
gh-119213: Fix getargs.c to store state in InterpreterState...
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; perhaps it would make sense to init getargs state just after _PyGC_Init, but I'm not sure it matters; I'll leave that kind of nitpicking to Eric :)
How does this work when the _PyArg_Parser instances are themselves declared as static variables (and are global to the process)? For example:
| static _PyArg_Parser _parser = { | |
| .keywords = _keywords, | |
| .fname = "Struct", | |
| .kwtuple = KWTUPLE, | |
| }; |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colesbury, I'm looking into what's going on. Basically, the statically declared tuple is only for builtin modules. I have a solution that's different from Yury's but want to be sure it's correct before closing this one.