http://pastie.org/1025197

Is it deemed acceptable that setting up one's own SIGCHLD handler breaks communicate()?

I did not find it in the documentation.

With the above workaround one can mix communicate() processes with processes spawned in the background that one's too lazy to wait for.

You should include all relevant issue materials here, in the Python issue tracker.  This ticket will be useless as soon as pastie.org decides to forget about your paste.

Content of the above pastie:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> import subprocess
>>> signal.signal(signal.SIGCHLD,signal.SIG_IGN)
0
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 698, in communicate
    self.wait()
  File "/usr/lib/python2.6/subprocess.py", line 1170, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.6/subprocess.py", line 465, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes
>>> oldsignal = signal.signal(signal.SIGCHLD,signal.SIG_DFL)
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
'blah\n'
>>> signal.signal(signal.SIGCHLD,oldsignal)
0

Can you suggest a specific doc patch with new text and location?

This has been fixed in 2.7 and 3.2 so I think that this issue can be closed.

Thanks for the problem report.  And thanks for noticing the fix.