Repository navigation
subprocess._USE_VFORK doesn't change usage of vfork #121381
Description
Activity
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.
Reacted by Cody Maloney- added a commit that references this issue
on Nov 30, 2025 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?
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
stracebased test isn't currently being run by any CI bots. Have a PR which both adds tests aroundreadand fixes the strace tests to run on some of the bots: #121143CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs