Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!news.davenulle.org!gegeweb.org!aioe.org!feeder.news-service.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=QLBF0AyB+fM0uNMBfbW8dMoGigwZejCAFQAdrjwhBHa8buq6kiRhN7yIIGmBRzwCWh nAZ26oz+ciHOB7R+Cfn7Qr9Ofw5fiaAz6poI28gWQ8fEahk3UPNqYMNwJwCBKpcZz60b gW1MlrMfG4kmSorb06+9fAvVtIIHOQ0k6KxR0=
Sender: "John O'Hagan" <johnmohagan@gmail.com>
From: "John O'Hagan" <research@johnohagan.com>
Organization: johnohagan.com
To: python-list@python.org
Subject: Re: Reassign or discard Popen().stdout from a server process
Date: Sat, 12 Feb 2011 05:32:01 +0000
User-Agent: KMail/1.13.5 (Linux/2.6.32-2011-01-16-16.13; KDE/4.4.5; i686; ; )
References: <mailman.1533.1296549030.6505.python-list@python.org> <mailman.72.1297326936.1633.python-list@python.org> <pan.2011.02.11.18.37.08.719000@nowhere.com>
In-Reply-To: <pan.2011.02.11.18.37.08.719000@nowhere.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.129.1297488734.1633.python-list@python.org>
Lines: 40
NNTP-Posting-Host: 82.94.164.166
Xref: csiph.com comp.lang.python: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