subprocess -- broken pipe error

Steve Holden steve at
Tue Jul 3 00:12:25 CEST 2007

7stud wrote:
> On Jul 2, 2:12 pm, Steve Holden <s... at> wrote:
>> a) Who told you pipes should be unbuffered by default, and b) what difference
>> does that make anyway?
> a) The docs.
> b) If the pipes were buffered then writing a small amount of data like
> "text3" to the pipe would cause the other side to hang forever thereby
> providing a possible explanation for the results.
>>> It just hangs, and then when I hit Ctrl+C and look in the file, the
>>> data isn't in there.
>> Of course it does, for the reasons mentioned above. only
>> returns when it has consumed *all* the data from the file (which means
>> the write must close the file for the reader to be able to return).
> That doesn't seem like a very good explanation, since the only thing
> written to the file(i.e. stdin) was "text3", and the write() was
> unbuffered, so the read() could consume all the data without the
> write() closing the file--there was no more data.

So please explain how the receiving process mysteriously manages to look 
inside your producer process to know that it is never going to produce 
any more data. Let's (briefly) look at the docs for read():

read( [size])

Read at most size bytes from the file (less if the read hits EOF before 
obtaining size bytes). If the size argument is negative or omitted, read 
all data until EOF is reached. ...

I believe you omitted the argument. As I have explained, the read() call 
therefore waits until the writer has closed the file. Which is what 
makes the EOF indication appear.

And please stop dragging buffering into this as a red herring. You do 
know what buffering *is*, I take it? The read() call buffers even an 
unbuffered source, by definition.

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd 
Skype: holdenweb
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

More information about the Python-list mailing list