Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 33.9k
gh-104372: Cleanup _posixsubprocess make_inheritable for async signal safety#104518
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
gpshead commented May 16, 2023 • edited by bedevere-bot
Loading Uh oh!
There was an error while loading. Please reload this page.
edited by bedevere-bot
Uh oh!
There was an error while loading. Please reload this page.
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.
gpshead commented May 16, 2023
This is a code cleanup that #104515 mentions as desirable so that a nicer PR can be made for the larger issue. |
bedevere-bot commented May 16, 2023
bedevere-bot commented May 16, 2023
Eclips4 commented May 16, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Fails in test_gzip, test_httpservers, test_nntplib, test_tarfile, test_xmlrpc related to isolation of io module. |
bedevere-bot commented May 16, 2023
bedevere-bot commented May 16, 2023
bedevere-bot commented May 16, 2023
gpshead commented May 17, 2023
!buildbot root |
bedevere-bot commented May 17, 2023
gpshead commented May 17, 2023
!buildbot Debian root |
bedevere-bot commented May 17, 2023
gpshead commented May 17, 2023
!buildbot AMD64 Debian root |
bedevere-bot commented May 17, 2023
gpshead commented May 17, 2023
!buildbot AMD64 Debian root |
bedevere-bot commented May 17, 2023
miss-islington commented May 17, 2023
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
miss-islington commented May 17, 2023
Sorry @gpshead, I had trouble checking out the |
bedevere-bot commented May 17, 2023
|
bedevere-bot commented May 17, 2023
|
bedevere-bot commented May 17, 2023
|
…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_AsLongandPyErr_OccurredandPyTuple_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