Alexey Izbyshev <izbys...@ispras.ru> added the comment:
> Is sys.platform equal to 'linux' on WSL? Sorry, I don't know WSL. If it's > equal, is it possible to explicitly exclude WSL in the subprocess test, > _use_posix_spawn()? I don't have immediate access to WSL right now, but I'll try to get one and investigate what we have there wrt. posix_spawn() and vfork(). > So the bug only affects "QEMU User Space". I never used that before. Yes, I was specifically referring to QEMU user-space. One use case that heavily relies on it is Tizen. Its packages are built in a chroot jail containing the build environment with binaries native to the target architecture, making an illusion that packages are built on the target system and are not cross-compiled. So the binaries are run under QEMU user-space emulation. But in reality, because of unacceptable performance of binary translation, many frequently-used binaries, like coreutils and compilers, are replaced with host-native binaries in a way transparent to the build system (so it has no idea whether it runs host-native or target-native binaries). > Does the difference matters? The bug only occurs in some very specific cases: > * WSL > * QEMU User Emulation > Are these use cases common enough to block the whole idea of using > posix_spawn() on Linux. I don't think so. I really want to use posix_spawn() > for best performances! Moreover, I expect that glibc implementation of > posix_spawn() is safer than Python _posixsubprocess. The glibc has access to > low-level stuff like it's internal signals, cancellation points, etc. > _posixsubprocess is more generic and doesn't worry about such low-level > stuff, whereas they might cause bad surprised. It's true that a C library is in a better position to implement something like posix_spawn(), but I still think that vfork()/exec() is worth to consider at least on Linux. See bpo-35823, which should also work under QEMU user-mode and WSL (but needs testing). ---------- _______________________________________ 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
