This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nanjekyejoannah
Recipients nanjekyejoannah, vstinner
Date 2018-12-19.16:47:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2018-12-19 16:47:59nanjekyejoannahsetrecipients: + nanjekyejoannah, vstinner
2018-12-19 16:47:59nanjekyejoannahsetmessageid: <>
2018-12-19 16:47:59nanjekyejoannahlinkissue35537 messages
2018-12-19 16:47:59nanjekyejoannahcreate