| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR makes some minor linting adjustments to the Lib/test module
caught by [ruff](https://github.com/charliermarsh/ruff). The adjustments
are all related to the `F541 f-string without any placeholders` issue.
Issue: https://github.com/python/cpython/issues/103805
<!-- gh-issue-number: gh-103805 -->
* Issue: gh-103805
<!-- /gh-issue-number -->
---------
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is strictly about moving the "obmalloc" runtime state from
`_PyRuntimeState` to `PyInterpreterState`. Doing so improves isolation
between interpreters, specifically most of the memory (incl. objects)
allocated for each interpreter's use. This is important for a
per-interpreter GIL, but such isolation is valuable even without it.
FWIW, a per-interpreter obmalloc is the proverbial
canary-in-the-coalmine when it comes to the isolation of objects between
interpreters. Any object that leaks (unintentionally) to another
interpreter is highly likely to cause a crash (on debug builds at
least). That's a useful thing to know, relative to interpreter
isolation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compatibility (gh-99040)
Enforcing (optionally) the restriction set by PEP 489 makes sense. Furthermore, this sets the stage for a potential restriction related to a per-interpreter GIL.
This change includes the following:
* add tests for extension module subinterpreter compatibility
* add _PyInterpreterConfig.check_multi_interp_extensions
* add Py_RTFLAGS_MULTI_INTERP_EXTENSIONS
* add _PyImport_CheckSubinterpIncompatibleExtensionAllowed()
* fail iff the module does not implement multi-phase init and the current interpreter is configured to check
https://github.com/python/cpython/issues/98627
|
| |
|
|
|
|
| |
of the normal location (GH-100947)
|
| |
|
|
|
|
| |
contains PYD files instead (GH-98936)
|
| |
|
|
|
|
|
|
|
| |
Previously, the optional restrictions on subinterpreters were: disallow fork, subprocess, and threads. By default, we were disallowing all three for "isolated" interpreters. We always allowed all three for the main interpreter and those created through the legacy `Py_NewInterpreter()` API.
Those settings were a bit conservative, so here we've adjusted the optional restrictions to: fork, exec, threads, and daemon threads. The default for "isolated" interpreters disables fork, exec, and daemon threads. Regular threads are allowed by default. We continue always allowing everything For the main interpreter and the legacy API.
In the code, we add `_PyInterpreterConfig.allow_exec` and `_PyInterpreterConfig.allow_daemon_threads`. We also add `Py_RTFLAGS_DAEMON_THREADS` and `Py_RTFLAGS_EXEC`.
|
|
|
|
|
|
|
|
|
|
|
| |
* As most of `test_embed` now uses `Py_InitializeFromConfig`, add
a specific test case to cover `Py_Initialize` (and `Py_InitializeEx`)
* Rename `_testembed` init helper to clarify the API used
* Add a `PyConfig_Clear` call in `Py_InitializeEx` to make
the code more obviously correct (it already didn't leak as
none of the dynamically allocated config fields were being
populated, but it's clearer if the wrappers follow the
documented API usage guidelines)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(gh-98609)
(see https://github.com/python/cpython/issues/98608)
This change does the following:
1. change the argument to a new `_PyInterpreterConfig` struct
2. rename the function to `_Py_NewInterpreterFromConfig()`, inspired by `Py_InitializeFromConfig()` (takes a `_PyInterpreterConfig` instead of `isolated_subinterpreter`)
3. split up the boolean `isolated_subinterpreter` into the corresponding multiple granular settings
* allow_fork
* allow_subprocess
* allow_threads
4. add `PyInterpreterState.feature_flags` to store those settings
5. add a function for checking if a feature is enabled on an opaque `PyInterpreterState *`
6. drop `PyConfig._isolated_interpreter`
The existing default (see `Py_NewInterpeter()` and `Py_Initialize*()`) allows fork, subprocess, and threads and the optional "isolated" interpreter (see the `_xxsubinterpreters` module) disables all three. None of that changes here; the defaults are preserved.
Note that the given `_PyInterpreterConfig` will not be used outside `_Py_NewInterpreterFromConfig()`, nor preserved. This contrasts with how `PyConfig` is currently preserved, used, and even modified outside `Py_InitializeFromConfig()`. I'd rather just avoid that mess from the start for `_PyInterpreterConfig`. We can preserve it later if we find an actual need.
This change allows us to follow up with a number of improvements (e.g. stop disallowing subprocess and support disallowing exec instead).
(Note that this PR adds "private" symbols. We'll probably make them public, and add docs, in a separate change.)
|
|
|
|
|
|
|
|
|
|
|
| |
It had to live as a global outside of PyConfig for stable ABI reasons in
the pre-3.12 backports.
This removes the `_Py_global_config_int_max_str_digits` and gets rid of
the equivalent field in the internal `struct _is PyInterpreterState` as
code can just use the existing nested config struct within that.
Adds tests to verify unique settings and configs in subinterpreters.
|
| |
|
|
|
|
|
|
|
| |
:warning: :warning: Note for reviewers, hackers and fellow systems/low-level/compiler engineers :warning: :warning:
If you have a lot of experience with this kind of shenanigans and want to improve the **first** version, **please make a PR against my branch** or **reach out by email** or **suggest code changes directly on GitHub**.
If you have any **refinements or optimizations** please, wait until the first version is merged before starting hacking or proposing those so we can keep this PR productive.
|
|
|
|
| |
command line (GH-28823)" (#94745)
|
| |
|
|
|
|
| |
Windows (GH-93888)
|
|
|
|
| |
calculation (GH-93641)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the -P command line option and the PYTHONSAFEPATH environment
variable to not prepend a potentially unsafe path to sys.path.
* Add sys.flags.safe_path flag.
* Add PyConfig.safe_path member.
* Programs/_bootstrap_python.c uses config.safe_path=0.
* Update subprocess._optim_args_from_interpreter_flags() to handle
the -P command line option.
* Modules/getpath.py sets safe_path to 1 if a "._pth" file is
present.
|
| |
|
| |
|
|
|
|
| |
PGInstrument on Windows (GH-32083)
|
|
|
|
|
| |
reinitialization (GH-32212)
Automerge-Triggered-By: GH:tiran
|
| |
|
|
|
| |
_Py_GetRefTotal() no longer decrements _PySet_Dummy refcount.
|
|
|
| |
Tolerate a leak of 1 reference and 1 memory block until it's fixed.
|
| |
|
| |
|
|
|
|
|
|
| |
* _testembed_Py_Initialize() now uses the PyConfig API, rather than
deprecated Py_SetProgramName().
* Reduce INIT_LOOPS from 16 to 4: test_embed now takes 8.7 seconds
rather than 14.7 seconds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add _PyStructSequence_FiniType() and _PyStaticType_Dealloc()
functions to finalize a structseq static type in Py_Finalize().
Currrently, these functions do nothing if Python is built in release
mode.
Clear static types:
* AsyncGenHooksType: sys.set_asyncgen_hooks()
* FlagsType: sys.flags
* FloatInfoType: sys.float_info
* Hash_InfoType: sys.hash_info
* Int_InfoType: sys.int_info
* ThreadInfoType: sys.thread_info
* UnraisableHookArgsType: sys.unraisablehook
* VersionInfoType: sys.version
* WindowsVersionType: sys.getwindowsversion()
|
|
|
|
| |
subprocess (GH-30595)
|
|
|
| |
This makes ntpath.abspath()/getpath_abspath() follow normpath(), since some WinAPIs such as PathCchSkipRoot() require backslashed paths.
|
|
|
|
|
| |
The condition is no longer valid. This should resolve the buildbot failure on FreeBSD.
https://bugs.python.org/issue46263
|
|
|
| |
This defines VPATH differently in PGO instrumentation builds, to account for a different default output directory. It also adds sys._vpath on Windows to make the value available to sysconfig so that it can be used in tests.
|
|
|
| |
Also ensures that pybuilddir.txt is written early enough in the build to be picked up by later steps.
|
| |
|
|
|
|
|
| |
The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code.
This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms.
|
|
|
|
|
|
|
| |
Rename PyConfig.no_debug_ranges to PyConfig.code_debug_ranges and
invert the value.
Document -X no_debug_ranges and PYTHONNODEBUGRANGES env var in
PyConfig.code_debug_ranges documentation.
|
| |
|
|
|
|
| |
when stdlib has been installed. (GH-29649)
|
|
|
|
|
| |
In gh-29063 I ended up disabling test_embed on non-Windows by accident. This gets it running again.
https://bugs.python.org/issue45506
|
| |
|
|
|
|
|
| |
We hadn't explicitly added any tests for this, so here they are.
https://bugs.python.org/issue45020
|
|
|
|
|
|
|
| |
(gh-29063)
In gh-28954 I adjusted how test_embed determines if it should be skipped. That broke out-of-tree builds. This change fixes them.
https://bugs.python.org/issue45506
|
|
|
|
|
|
|
| |
(gh-28940)
The default was "off". Switching it to "on" means users get the benefit of frozen stdlib modules without having to do anything. There's a special-case for running-in-source-tree, so contributors don't get surprised when their stdlib changes don't get used.
https://bugs.python.org/issue45020
|
|
|
|
|
| |
The change in gh-28586 (bpo-45211) should not have included code to set _Py_path_config.stdlib_dir in Py_SetPythonHome(). We fix that here.
https://bugs.python.org/issue45471
|
|
|
|
| |
(GH-28823)
|