Donovan Baarda wrote: > Consider the following. This is pretty much the only way you can use > popen2 reliably without knowing specific behaviours of the executed > command; > > ... > fcntl.fcntl(child_in, fcntl.F_SETFL, flags | os.O_NONBLOCK) # \ > ... # / > fcntl.fcntl(child_out, fcntl.F_SETFL, flags | os.O_NONBLOCK)# \ I still don't believe you need to make these non-blocking. When select() returns a fd for reading/writing, it's telling you that the next os.read/os.write call on it will not block. Making the fd non-blocking as well is unnecessary and perhaps even undesirable. > For 1) and 2), note that popen2 returns file objects, but as they cannot > be reliably used as file objects, we ignore them and grab their > fileno(). Why does popen2 return file objects if they cannot reliably be > used? I would go along with giving file objects alternative read/write methods which behave more like os.read/os.write, maybe called something like readsome() and writesome(). That would eliminate the need to extract and manipulate the fds, and might make it possible to do some of this stuff in a more platform-independent way. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing at canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4