Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #55516 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Reassign or discard Popen().stdout from a server process Nobody <nobody@nowhere.com> - 2011-02-11 18:37 +0000
    Re: Reassign or discard Popen().stdout from a server process "John O'Hagan" <research@johnohagan.com> - 2011-02-12 05:32 +0000

#55516 — Re: Reassign or discard Popen().stdout from a server process

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.

[toc] | [next] | [standalone]

#55705

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web