-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-22257: Private C-API for core runtime initialization (PEP 432). #1772
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
bpo-22257: Private C-API for core runtime initialization (PEP 432). #1772
Conversation
@ericsnowcurrently, thanks for your PR! By analyzing the history of the files in this pull request, we identified @zooba, @ncoghlan and @birkenfeld to be potential reviewers. |
2caf35c
to
6573e10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with the fixes mentioned
Python/pylifecycle.c
Outdated
*/ | ||
|
||
/* #define _INIT_DEBUG_PRINT(msg) printf(msg) */ | ||
#define _INIT_DEBUG_PRINT(msg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to stay? Should we have a build option to reenable it? Or a comment explaining it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for dropping it (this is brute force debugging hackery left over from when the modified interpreter was crashing on startup)
Python/pylifecycle.c
Outdated
that we can call Py_Initialize / Py_FinalizeEx multiple times. */ | ||
_PyEval_FiniThreads(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's with the change in this section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. Given the comment I expect it wasn't intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost certainly the result of a merge glitch somewhere along the line when I was still maintaining the patch out of tree.
Python/pylifecycle.c
Outdated
if (!tstate) | ||
Py_FatalError("Py_Initialize: failed to read thread state"); | ||
interp = tstate->interp; | ||
if (!tstate) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!interp)
core_config.ignore_environment = Py_IgnoreEnvironmentFlag; | ||
core_config._disable_importlib = !install_importlib; | ||
_Py_InitializeCore(&core_config); | ||
_Py_InitializeMainInterpreter(install_sigs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where we'd trigger the extra initialization step, right?
Also, why not put install_sigs
into core_config
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of those are sorted out in the next PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But for anyone just reading these comments: "install_sigs" becomes the first field in the new config struct for the main interpreter, rather than being needed to get the core runtime going :)
6573e10
to
6deccd5
Compare
(Patch by Nick Coghlan / @ncoghlan)
Mostly this adds _PyCoreConfig/_Py_InitializeCore() and reorganizes interpreter initialization code around them. The changes align with PEP 432. The new functions are introduced here as "private" C-API while the PEP is discussed. Regardless of the status of the PEP, the changes here are an improvement to interpreter startup. As such we are making the changes now, but keeping the C-API private.