Pablo Galindo Salgado <pablog...@gmail.com> added the comment:
The removal of POSIX_SPAWN_USEVFORK in glibc was somewhat recent. There is also multiple implementations of posix_spawn in glibc source tree. vfork was introduced in commit 9ad684229e7cf2f0b3c6068b2122701d167a5794 Author: Ulrich Drepper <drep...@redhat.com> Date: Sun Sep 12 18:05:37 2004 +0000 The new implementation of posix_spawn for unix (/sysdeps/unix/sysv/linux/spawni.c) was introduced in commit 9ff72da471a509a8c19791efe469f47fa6977410 Author: Adhemerval Zanella <adhemerval.zane...@linaro.org> Date: Tue Jan 19 17:33:32 2016 -0200 The new implementation of posix_spawn for posix (sysdeps/posix/spawni.c) was introduced in commit ccfb2964726512f6669fea99a43afa714e2e6a80 Author: Adhemerval Zanella <adhemerval.zane...@linaro.org> Date: Mon Apr 24 15:50:19 2017 -0300 In these two last commits, posix_spawn removed the flag and made it a no-op. But notice that these commits are "recent" (2016 and 2017). Any older version of glibc that uses python will not benefit from these changes and if it wants to use vfork, it needs the flag. At this point and after this interesting discussion I am not sure that we should expose the flag or not, but I still want to remark that even if glibc removed the flag for both implementations (unix and posix) we may want to expose the flag for older versions of glibc. I discover this problem when I was benchmarking posix_spawn in different platforms and systems and I notice a performance decrease in some older version of ubuntu from 2015. In that platform (older version of glibc) you need the flag to activate vfork and get the performance benefit. The glibc version for this systems is straightforward: - if ((flags & POSIX_SPAWN_USEVFORK) != 0 - /* If no major work is done, allow using vfork. Note that we - might perform the path searching. But this would be done by - a call to execvp(), too, and such a call must be OK according - to POSIX. */ - || ((flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF - | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER - | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS - | POSIX_SPAWN_SETSID)) == 0 - && file_actions == NULL)) - new_pid = __vfork (); - else - new_pid = __fork (); I am happy to close the issue if everyone agrees that we should look at the future and not care about these older versions of glibc < 2017/2016 (depending on posix/unix version) or this does not worth the hassle. I am still happy with this great and interesting discussion, so thank you everyone :) Complete story of posix_spawn in glibc: Whole story of posix_spawn: commit c181840c93d3a8fcb50991b2326c40f34eb5e82b commit c22845744cd931267e0d7cb2e2b35a0da9c9510a commit db6b2f25220f1cf345656164211fd549c22189dd commit ccfb2964726512f6669fea99a43afa714e2e6a80 commit daeb1fa2e1b33323e719015f5f546988bd4cc73b commit 1a2325c06cf309d1d8b4aafcfb1a3d43905baf9b commit ecb1482ffd85fd3279642b1dc045aa867ad4d415 commit d96de9634a334af16c0ac711074c15ac1762b23c commit f574184a0e4b6ed69a5d9a3234543fba6d2a7367 commit cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca commit 1b8373f475105307ee3b64d423ffec995ddd6cde commit 7231452e5cffcd506f7e7402484708740bc07c18 commit a334319f6530564d22e775935d9c91663623a1b4 commit 0ecb606cb6cf65de1d9fc8a919bceb4be476c602 commit 9ad684229e7cf2f0b3c6068b2122701d167a5794 commit 73299943388c0eebf6a9c8d6288e9da8289f9dca commit 284128f68f27567f9cad0078c97d7d807475e0a7 commit ba3752d5322448ab54b71c82e63a09542042a3b6 commit 2958e6cc5f39ac2487b4fcbc2db48462a34ce23d commit 4aebaa6bd906383aca1b7a5e1251b0d1652f9f7c commit 08c7f6b0082b1b645348518fdc42643b5580d87c commit a5a6f9262eeffab9f78622258fae306d1bf99d04 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34663> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
