New submission from Joannah Nanjekye <nanjekyejoan...@gmail.com>:
On Linux, posix_spawn() uses vfork() instead of fork() which blocks the parent process. The child process executes exec() early and so we don't pay the price of duplicating the memory pages (the thing which tracks memory pages of a process). On macOS, posix_spawn() is a system call, so the kernel is free to use fast-paths to optimize it as they want. posix_spawn() is faster but it's also safer: it allows us to do a lot of "actions" before exec(), before executing the new program. For example, you can close files and control signals. Again, on macOS, these actions are "atomic" since it's a system call. On Linux, glibc uses a very good implementation which has no race condition. Currently, Python uses a C extension _posixsubprocess which more or less reimplements posix_spawn(): close file descriptors, make some file descriptors inheritable or not, etc. It is very tricky to write correct code: code run around fork() is very fragile. In theory, the POSIX specification only allows to use "async-signal-safe" functions after fork()... So it would be great to avoid _posixsubprocess whenever possible for (1) speed (2) correctness. ---------- components: Library (Lib) messages: 332151 nosy: nanjekyejoannah, vstinner priority: normal pull_requests: 10472 severity: normal status: open title: use os.posix_spawn in subprocess type: enhancement versions: Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35537> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
