select() vs. pipes (was [Python-Dev] Re: PEP 324 (process module)) (original) (raw)

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 (pout is always in the ready state; the select timeout is never reached).

But if you comment out the "os.close(pin)" 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 "", 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