It's quite amazing that communicate() actually cannot be trusted or is simply not implemented correctly :/.

Well, you are quite right - communicate() CAN be trusted.

I did a small experiment of reading a Gbyte, both in PY27 and PY35, and they do not block:

>>> import subprocess as sb
>>> proc=sb.Popen('dd if=/dev/zero bs=1024 count=1000000', bufsize=0, stdin=sb.PIPE, stdout=sb.PIPE, stderr=sb.PIPE)
>>> a,b=proc.communicate()

I don't remember when I got this mistrust for communicate(), maybe when I had tried PY33, or maybe when epxerimenting with interactive processes (like the git.cmd.Git.cat-file persistent command); there the comminicate() is not suitable because it will start consuming streams till the death of the process, but the process is awaiting for more input from python-side before ending, so it's a deadlock.

One or two changes in my windows fixes were under this wrong assumption that communicate() should not be trusted. But mostly I replaced code accessing directly proc.stderr/stdout from the main thread - this is definitely freeze-prone code.

A nice experiment ! It doesn't seem to output both on stdout and stderr though, which might be causing the problem we see. The implementation of communicate looks asynchronous, but who knows what's hidden in the details.

Even when stdout/stderr is interplexed, communicate() does not block (at least in PY3):

>>> import subprocess as sb
>>> proc = sb.Popen(['python','-c',"import sys\nfor i in range(1000000):\n    print('a'*1024); print('b'*1024, file=sys.stderr)"], stdin=sb.PIPE, stdout=sb.PIPE, stderr=sb.PIPE)
>>> %time a,b=proc.communicate()
Wall time: 48.3 s
>>> len(a), len(b)
(1026000000, 1026000000)

For some "unicode" reason cannot run the above experiment in PY2.