Antoine Pitrou <pit...@free.fr> added the comment:
@Elad: > I'm not convinced that a multi-threaded fork()+exec() from C would be any > better, unless the Python code goes to great lengths to avoid any > non-async-signal-safe operations between the fork() and the exec(). That's exactly what the C code in the C subprocess module for POSIX does, though: https://github.com/python/cpython/blob/master/Modules/_posixsubprocess.c#L828-L854 That's why I hope that using subprocess instead of a fork()+exec() sequence naively coded in pure Python would solve the issue. @Guido: > I can sort of see why you consider the small example a red herring, since it > mixes threads and fork Perhaps "red herring" was the wrong expression. What I mean is that it's no surprise that fork()+exec() sequence written in pure Python would be unsafe in multi-thread settings. The solution, though, is not to avoid threads or try to workaround the issue in ThreadPoolExecutor, but rather to avoid doing fork()+exec() in pure Python. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39763> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
