Reassign or discard Popen().stdout from a server process
nobody at nowhere.com
Fri Feb 11 19:37:16 CET 2011
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.
More information about the Python-list