Description
Bug report
(See https://discuss.python.org/t/clarification-on-pep-734-subinterpreters-with-embedded-c-api/45889/1)
The test fails if CPython (main/3.13) is embedded without using Py_Main()
. This is because Py_Main()
calls _PyInterpreterState_SetRunningMain()
. which is a new internal API that embedders are unlikely to even know about.
The failure can be reproduced in a regular build by commenting out the _PyInterpreterState_SetRunningMain()
and _PyInterpreterState_SetNotRunningMain()
calls in Modules/main.c:
(expand)
diff --git a/Modules/main.c b/Modules/main.c
index df2ce55024..5c0cb8222d 100644
--- a/Modules/main.c
+++ b/Modules/main.c
@@ -612,7 +612,7 @@ pymain_run_python(int *exitcode)
pymain_header(config);
- _PyInterpreterState_SetRunningMain(interp);
+// _PyInterpreterState_SetRunningMain(interp);
assert(!PyErr_Occurred());
if (config->run_command) {
@@ -638,7 +638,7 @@ pymain_run_python(int *exitcode)
*exitcode = pymain_exit_err_print();
done:
- _PyInterpreterState_SetNotRunningMain(interp);
+// _PyInterpreterState_SetNotRunningMain(interp);
Py_XDECREF(main_importer_path);
}
FTR, I added the "running"-tracking API (1dd9dee) to support PEP 734's Interpreter.is_running()
. The PEP hasn't been accepted yet, but we still use the implementation to exercise subinterpreters in the test suite.
Possible solutions:
- always assume the main interpreter is running (in the main thread)
- make calls to the “running”-tracking API implicit to calls to the PyRun_*() family (and similar)
- infer the “running”-tracking API should have been called in certain situations
- make it public API
- stop tracking if an interpreter is “running” (i.e. drop the API and the related state)
I plan on implementing a short-term fix right away. If we keep "running"-tracking then we'll definitely at least want to make the API public.
Linked PRs
Metadata
Metadata
Assignees
Labels
Projects
Status