select() vs. pipes (was [Python-Dev] Re: PEP 324 (process module))
Peter Astrand
astrand at lysator.liu.se
Wed Aug 4 21:01:22 CEST 2004
> Sorry for going off-topic, but this program (UNIX-only):
> ... will busywait in select (p_out is always in the ready state; the
> select timeout is never reached).
>
> But if you comment out the "os.close(p_in)" line, it no longer busywaits
> (the select timeout is reached on every iteration). At least this is
> the behavior under Linux.
This isn't strange. You are closing the (only) read-end of the pipe. When
you do this, the pipe is broken. Consider this:
>>> import os
>>> r, w = os.pipe()
>>> os.close(r)
>>> os.write(w, "a")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OSError: [Errno 32] Broken pipe
select() only indicates that something has happened on this
filedescriptor.
> This is a little unfortunate because the normal dance when communicating
> between parent and child in order to capture the output of a child
> process seems to be:
>
> 1) In the parent process, create a set of pipes that will represent
> stdin/stdout/stderr of the child.
>
> 2) fork
The problem with your example was that it didn't fork...
So, there is no problem with using select() on pipes when communicating
with a subprocess. It works great. Take a look at (my) process.py's
communicate() method for some inspiration.
/Peter Åstrand <astrand at lysator.liu.se>
More information about the Python-Dev
mailing list