-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
del-safe symbols in subprocess module cannot be overwritten in cross-build environment #112736
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
Labels
type-bug
An unexpected behavior, bug, or error
Comments
gpshead
pushed a commit
that referenced
this issue
Dec 5, 2023
Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
The PR has been merged: okay to close this issue now, or more to do? |
My apologies - forgot about the issue. Yes, it can be closed. |
aisk
pushed a commit
to aisk/cpython
that referenced
this issue
Feb 11, 2024
…hon#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Aug 5, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Aug 5, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Aug 5, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Aug 5, 2024
python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
Glyphack
pushed a commit
to Glyphack/cpython
that referenced
this issue
Sep 2, 2024
…hon#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Sep 6, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Sep 9, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Sep 9, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Sep 9, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Sep 9, 2024
python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Oct 9, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Dec 13, 2024
python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Dec 13, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Dec 13, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
freakboy3742
added a commit
to freakboy3742/cpython
that referenced
this issue
Dec 13, 2024
…ss (python#112738) Refactor delete-safe symbol handling in subprocess. Only module globals are force-cleared during interpreter finalization, using a class reference instead of individually listing the constants everywhere is simpler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report
Bug description:
The subprocess module has a number of symbols that must be available during the deletion process. To ensure this, the symbols that must be available for deletion are pre-declared, then used as the default value of arguments of methods. For example, see the handling of
_waitstatus_to_exitcode
,_WIFSTOPPED
and_WSTOPSIG
in_handle_exitstatus
.However, in a cross-platform compilation environment, this poses a problem. The approach taken by cross-platform environments (such as crossenv) is to build a hybrid environment by creating a virtual environment on the build machine, then monkeypatch any standard library module that has platform-specific properties. This allows code to execute using build platform executables, but return properties of the host platform as required.
By binding specific constant values as arguments, those values can't be overwritten by a monkeypatch; e.g.,:
This won't work, because
_waitpid
has already been bound as an argument in the methods that use it when the subprocess module was imported.Most historical cross platform compilation environments won't be affected by this, as both the build and host platform will support subprocesses, so there either isn't a need to patch the subprocess module, or the constants on the build and host are the same. However, when building a cross-platform build environment for iOS, the build platform supports subprocesses, but iOS doesn't, and there is a need to monkeypatch the delete-safe symbols so that the hybrid environment disables subprocesses.
If the symbols that need to be delete-safe were gathered into a single wrapper object, it would both simplify the process of passing in the delete safe properties (as you only need to bind a single object acting as a namespace), and allow for cross-platform environments to monkeypatch the symbols, as the monkeypatch can modify the properties of the namespace object:
This will work, because
_del_safe
is the object that has been bound as an argument, andwaitpid
is a property of that object.CPython versions tested on:
3.13
Operating systems tested on:
Other
Linked PRs
The text was updated successfully, but these errors were encountered: