STINNER Victor added the comment: The new asyncio module doesn't have this performance issue: it allows to wait asynchronously for the process exit without busy loop.
Right now, there is no high-level API for that, but it is very likely that Python 3.4 final will provide a simple proc.wait() method for that. See #20400 and related Tulip issue: http://code.google.com/p/tulip/issues/detail?id=115 On Unix, the default implementation sets an handler for SIGCHLD signal which calls waitpid(pid, WNOHANG) on all processes to detect process exit. But it has also a faster implementation which calls waitpid(-1, WNOHANG) only once. asyncio uses signal.set_wakeup_fd() to wake up its event loop when it gets a signal. Charles-François wrote: > Honestly, I think the extra complexity and non-portability isn't worth it. I agree. And any change may break the backward compatibility, because signal handling is tricky and many detail are platform specific. asyncio is well designed and solves this issue in a portable way. On Windows, RegisterWaitWithQueue() is used with an overlapped object and a proactor event loop to wait for the process exit. I leave the issue open until all the new subprocess code is merged into Tulip and Python asyncio. ---------- nosy: +gvanrossum versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12187> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
