<div class="gmail_quote">On Mon, Jan 26, 2009 at 4:43 PM, Nick Coghlan <span dir="ltr">&lt;<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
With the vanilla subprocess Popen implmentation, the stdin.write calls<br>
can actually both block if the stdin buffer is full (waiting for the<br>
child process to clear space) and the stdout.readline call can<br>
definitely block (waiting for the child process to end the line).</blockquote><div><br>That&#39;s true, but for the use cases presented so far, .readline() is satisfactory, unless you have an unusual application that will fill the pipe without sending a single newline (in which case, see below).<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So it isn&#39;t async communication in general that is the concern: it is<br>
*non-blocking* async communication. (Since I&#39;m happy with the idea of<br>
threaded programs, I&#39;d personally just farm the task off to some worker<br>
threads and make it non-blocking that way, but that approach effectively<br>
abandons the whole concept of non-blocking IO and it&#39;s ability to avoid<br>
using threads).</blockquote></div><br>If you really need to communicate with multiple subprocesses (which so far has not been suggested as a motivating example), then you can use select().<br><br>You don&#39;t need non-blocking IO to avoid using threads (although that is a common misconception).&nbsp; If a program never blocks, then it uses 100% of CPU by definition, which is undesirable. ;-)&nbsp; A program just needs select() so it knows which file descriptors it can call os.read() or os.write() on without blocking.<br>
<blockquote style="margin: 1.5em 0pt;">--<br>
Daniel Stutzbach, Ph.D.<br>
President, <a href="http://stutzbachenterprises.com">Stutzbach Enterprises, LLC</a>
</blockquote>