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 -- http://mail.python.org/mailman/listinfo/python-list
