subprocess._USE_VFORK doesn't change usage of vfork #121381
Description
Bug report
Bug description:
Discussion: https://discuss.python.org/t/subprocess-use-vfork-escape-hatch-broken-fix-or-remove/56915
This flag was added as an escape hatch in gh-91401 and backported to Python 3.10. The flag broke at some point between its addition and now. As there is currently no publicly known environments that require this, planning to remove it rather than work on fixing it.
I found that the test for this was broken while working on tests for reducing system calls in other cases (GH-120754). The strace based test isn't currently being run by any CI bots. Have a PR which both adds tests around read and fixes the strace tests to run on some of the bots: #121143
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Activity
hauntsaninja commentedon Jul 7, 2024
Sanity checking the results of https://grep.app/search?q=_USE_VFORK&case=true&filter[lang][0]=Python and https://github.com/search?q=_USE_VFORK+language%3APython+&type=code , I think it would be fine to remove. It's clearly a private API. The billiard code would break a little unfortunately, but they're reading it unchecked despite the documentation explicitly saying not to do so, they're using internals and they have a bunch of version specific code anyway. The gevent hit just looks like a fork of test_subprocess.py for each minor version of Python.
gh-121381 Remove subprocess._USE_VFORK escape hatch (#121383)
pythongh-121381 Remove subprocess._USE_VFORK escape hatch (python#121383
fix(run): configure spawn start method on macOS to avoid fork warnings (
miamia0 commentedon Sep 9, 2026
Is there any supported configuration in current CPython to make subprocess use fork() instead of vfork() on Linux? it looks like the private subprocess._USE_VFORK escape hatch was broken and then removed in 3.14; are users expected to avoid vfork-triggering cases only, or is a supported opt-out planned?