Issue 481896: popen3 file objects hanging (original) (raw)

Issue481896

Created on 2001-11-14 23:13 by anonymous, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Messages (3)
msg7543 - (view)	Author: Nobody/Anonymous (nobody)	Date: 2001-11-14 23:13
RE:#210676 System: Python 2.0 on solaris 8 The above bug is reported closed but I cannot see why. >>> sub = popen2.Popen3(cmd,1) >>> sub.fromchild.readlines() # blocked on stderr As reported in the above sited bug report, we too are suffering from this behaviour on file objects returned by popen3. It does appear that the stderr buffer is filling (the app writes a lot of stuff to stderr) and blocking stdout, but i cannot seem to flush the buffer. I need to acquire both stderr and stdout data. I have tried setting the bufsize to 0 (unbuffered) but that doesn't work. I have made the buffer big, but nothing there. Might there be some magic bufsize? popen4 (which stuffs both stderr and stdout into one file object) works perfectly as there is no blocking. Reading through the bugs about popen3, the bug report above is exactly what we are experiencing. The "solution" offered is not a solution at all. We are running 3rd party code, i.e. we can't close stderr inside the application, nor would we want to. stderr and stdout file descriptors must remain open for the duration of the application. Has there been some viable solution to this which has not been documented?
msg7544 - (view)	Author: Gustavo Niemeyer (niemeyer) *	Date: 2002-11-12 01:31
Logged In: YES user_id=7887 You can workaround the problem in the following ways: 1) as martin explained in the previous mentioned bug; 2) using non-blocking I/O: fd = pop.childerr.fileno() flags = fcntl.fcntl (fd, fcntl.F_GETFL, 0) flags = flags | os.O_NONBLOCK fcntl.fcntl (fd, fcntl.F_SETFL, flags) 3) piping the child error into /dev/null, if you don't want it. Either way, IMO that's something which belongs to how the operating system deals with that, since there's no way for Python to guess what you'd expect it to do in all possible cases, and it probably shouldn't try to. I suggest closing that bug.
msg7545 - (view)	Author: A.M. Kuchling (akuchling) *	Date: 2003-02-06 18:15
Logged In: YES user_id=11375 Marking as closed. (Unless someone can suggest text to be added to the documentation to clarify this?)