-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
gh-104372: Cleanup _posixsubprocess make_inheritable
for async signal safety
#104518
Conversation
We move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process.
This is a code cleanup that #104515 mentions as desirable so that a nicer PR can be made for the larger issue. |
Fails in test_gzip, test_httpservers, test_nntplib, test_tarfile, test_xmlrpc related to isolation of io module. |
!buildbot root |
!buildbot Debian root |
!buildbot AMD64 Debian root |
!buildbot AMD64 Debian root |
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry @gpshead, I had trouble checking out the |
|
|
|
…c signal safety and no GIL requirement (python#104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways.
…or async signal safety and no GIL requirement (pythonGH-104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways.. (cherry picked from commit c649df6) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…or async signal safety and no GIL requirement (pythonGH-104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways.. (cherry picked from commit c649df6) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…or async signal safety and no GIL requirement (pythonGH-104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways.. (cherry picked from commit c649df6) Co-authored-by: Gregory P. Smith <greg@krypto.org>
…c signal safety and no GIL requirement (python#104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways. (cherry picked from commit c649df6)
…or async signal safety and no GIL requirement (pythonGH-104518) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways.. (cherry picked from commit c649df6) Co-authored-by: Gregory P. Smith <greg@krypto.org>
… signal safety gh-104518 (#104785) Move all of the Python C API calls into the parent process up front instead of doing PyLong_AsLong and PyErr_Occurred and PyTuple_GET from the post-fork/vfork child process. Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of these low level functions anyways. This is a backport of c649df6 for #104518 and the tiny adjustment in d1732fe #104697. Backporting this allows backporting of the real bug fix that requires it. Co-authored-by: Gregory P. Smith [Google] <greg@krypto.org>
We move all of the Python C API calls into the parent process up front instead of doing
PyLong_AsLong
andPyErr_Occurred
andPyTuple_GET*
from the post-fork/vfork child process.Much of this was long overdue. We shouldn't have been using PyTuple and PyLong APIs within all of the lower level functions anyways.
vfork()
until the child processexec()
succeeds or fails. #104372