Python select() 行为很奇怪

Question

我在理解 select.select 的行为时遇到一些困难。请考虑以下 Python 程序：

def str_to_hex(s):
    def dig(n):
        if n > 9:
            return chr(65-10+n)
        else:
            return chr(48+n)
    r = ''
    while len(s) > 0:
        c = s[0]
        s = s[1:]
        a = ord(c) / 16
        b = ord(c) % 16
        r = r + dig(a) + dig(b)
    return r

while True:
    ans,_,_ = select.select([sys.stdin],[],[])
    print ans
    s = ans[0].read(1)
    if len(s) == 0: break
    print str_to_hex(s)

我已将其保存到文件“test.py”中。如果按如下方式调用它：

echo 'hello' | ./test.py

那么我会得到预期的行为： select 永远不会阻塞并且所有数据都会被打印；然后程序终止。

但如果我以交互方式运行该程序，我会得到最不希望的行为。请考虑以下控制台会话：

$ ./test.py
hello
[<open file '<stdin>', mode 'r' at 0xb742f020>]
68

然后程序挂在那里； select.select 现在再次阻塞。直到我提供更多输入或关闭输入流后，才会打印下一个字符（以及所有其余字符），即使已经有字符在等待！谁能向我解释这种行为？我在我编写的流隧道程序中看到类似的东西，它破坏了整个事件。

感谢您的阅读！

Answer 1

sys.stdin 的 read 方法工作在比 select 更高的抽象级别上。当您执行 ans[0].read(1) 时，Python 实际上会从操作系统读取大量字节并在内部缓冲它们。 select 不知道这种额外的缓冲；它只看到所有内容都已被读取，因此将阻塞，直到 EOF 或更多输入到达。您可以通过运行诸如 strace -e read,select python yourprogram.py 之类的命令来观察此行为。

一种解决方案是将 ans[0].read(1) 替换为 os.read(ans[0].fileno(), 1)。 os.read 是一个较低级别的接口，它和操作系统之间没有任何缓冲，因此它更适合 select。

或者，使用 -u 命令行选项运行 python 似乎也会禁用额外的缓冲。

Answer 2

它正在等待您发出 EOF 信号（交互使用时可以使用 Ctrl+D 来执行此操作）。您可以使用 sys.stdin.isatty() 来检查脚本是否正在交互运行，并相应地处理它，使用 raw_input 代替。我还怀疑您是否需要使用 select.select ，为什么不只使用 sys.stdin.read 呢？

if sys.stdin.isatty():
    while True:
        for s in raw_input():
            print str_to_hex(s)
else:
    while True:
        for s in sys.stdin.read(1):
            print str_to_hex(s)

这使得它既适合交互式使用，又适合流处理。