Reassign or discard Popen().stdout from a server process
John O'Hagan
research at johnohagan.com
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.
John
More information about the Python-list
mailing list