Reassign or discard Popen().stdout from a server process

John O'Hagan research at
Sat Feb 12 00:32:01 EST 2011

On Fri, 11 Feb 2011, Nobody wrote:
> On Thu, 10 Feb 2011 08:35:24 +0000, John O'Hagan wrote:
> >> > But I'm still a little curious as to why even unsuccessfully
> >> > attempting to reassign stdout seems to stop the pipe buffer from
> >> > filling up.
> >> 
> >> It doesn't. If the server continues to run, then it's ignoring/handling
> >> both SIGPIPE and the EPIPE error. Either that, or another process has
> >> the read end of the pipe open (so no SIGPIPE/EPIPE), and the server is
> >> using non-blocking I/O or select() so that it doesn't block writing its
> >> diagnostic messages.
> > 
> > The server fails with stdout=PIPE if I don't keep reading it, but
> > doesn't fail if I do stdout=anything (I've tried files, strings,
> > integers, and None) soon after starting the process, without any other
> > changes. How is that consistent with either of the above conditions? I'm
> > sure you're right, I just don't understand.
> What do you mean by "fail". I wouldn't be surprised if it hung, due to the
> write() on stdout blocking. If you reassign the .stdout member, the
> existing file object is likely to become unreferenced, get garbage
> collected, and close the pipe, which would prevent the server from
> blocking (the write() will fail rather than blocking).
> If the server puts the pipe into non-blocking mode, write() will fail with
> EAGAIN if you don't read it but with EPIPE if you close the pipe. The
> server may handle these cases differently.

By "fail" I mean the server, which is the Fluidsynth soundfont rendering 
program, stops producing sound in a way consistent with the blocked write() as 
you describe. It continues to read stdin; in fact, Ctrl+C-ing out of the block 
produces all the queued sounds at once. 

What I didn't realise was that the (ineffective) reassignment of stdout has the 
side-effect of closing it by dereferencing it, as you explain above. I asked on 
the Fluidsynth list and currently it ignores if the pipe it's writing to has 
been closed . All makes sense now, thanks.


More information about the Python-list mailing list