RetroSearch Browse

Wed Aug 4 21:01:22 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/046827.html

> 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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046827.html below:

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