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.