linux - VMIN=0 + select()，可能是内核错误？

Question

更新: Simple Proof of Concept解释不同的行为。

假设我使用 tcgetattr 和 tcsetattr 设置 VMIN = 0, VTIME = 0 并删除 ICANON，将终端设置为原始模式。从 stdin 调用 read() 永远不会阻塞。我说得对吗？

我的问题是:我应该期望标准输入上的 select() 立即返回吗？
从手册页:

select() and pselect() allow a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become "ready" for some class of I/O operation (e.g., input possible). A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking.

基于此，我的第一个回答是"is"。但是，实际上它确实在我测试过的大多数 Linux 系统上会阻塞，但在某些系统上不会阻塞。 这是内核错误吗？ 是否建议以这种方式使用 VMIN = 0 和 select()？

Answer 1

问题可能是这样的:VMIN 的数组条目和 VTIME有两个目的。引用POSIX termios :

the VMIN and VTIME subscripts may have the same values as the VEOF and VEOL subscripts, respectively.

程序读取attributes规范模式下的值，然后将其更改为非规范模式，并设置 VMIN归零。但是 version shown对 VTIME 什么都不做(这与问题中的描述不符)。

参见示例 Understanding UNIX termios VMIN and VTIME (同样，Linux manual page 用于 termios)，它指出如果两个 VMIN和 VTIME为零，那么您就可以进行完全非阻塞的读取。

termios 手册页将零作为 VEOL 的初始值, 而 stty manual页等于<undef>与 _POSIX_VDISABLE (非零)(与 POSIX stty 一致)。 POSIX 似乎没有为 eol 指定初始值.

通常 VEOL将是 <undef>如图所示 stty -a .也许在您获得非阻塞读取的机器上，情况并非如此。这不一定是内核错误，但可能是 TTY 的配置问题。