在什么情况下从流（末尾）读取会导致停顿？答案

【问题标题】：Under what conditions does reading from (the end of) a stream cause stalling?在什么情况下从流（末尾）读取会导致停顿？
【发布时间】：2017-06-19 23:12:28
【问题描述】：

我的问题与使用文件描述符有关，它可以是标准输入或打开的文件。

我想弄清楚：

在什么情况下从流中读取会导致停止。为什么cin >> x 等待用户输入，但据我所知，打开的文件上的fgets(line, len, file) 永远不会停止。（我知道拖延对于读取文件没有意义，但我正试图弄清楚流在这里是如何工作的。）
如何检测已打开文件与标准输入的流结束？似乎当您从 Stdin 读取时，如果您在最后，它会等待输入。如果从文件中读取并且您在最后，则会以某种方式触发 EOF 并且它不会停止。而且我认为 Stdin 的流结束不一定意味着输入的结束，只是程序已经读取了到目前为止所有可用的输入，对吧？

【问题讨论】：

C 标签不相关，fgets() 的行为在 C 和 C++ 之间可能不同。
如果file 参数为stdin（例如），fgets 可以阻塞，或者如果底层 I/O 设备阻塞，则实际上只是阻塞。
有什么具体的测试用例会触发stalling？你已经知道Why is iostream::eof inside a loop condition considered wrong?了？
@Stargateur - 尽管 C++ 标准委托给 <cstdio> 的 C 标准...
那是因为标准输入没有结尾。（除非它来自文件）

标签： c++ stream

【解决方案1】：

使用cin（或另一个istream）与fgets（或fscanf等）阅读之间基本上没有区别

在这两种情况下，如果您从标准输入读取，它们将停止等待输入，并在收到标准输入已到达文件末尾的正确指示时返回 EOF（例如，ctrl +d 在 Linux 上，ctrl+z 或 F6 在 Windows 上）。当然，如果标准输入被重定向到一个文件，程序会像往常一样感知文件的结尾。

同样，在这两种情况下，它们实际上在从磁盘上的文件中读取数据时会停止——但至少在典型情况下，仍然是几十毫秒的量级，所以一个人通常不会察觉到它。尽管如此，是的，当 CPU 向驱动器控制器发出读取命令时，在数据从磁盘驱动器到达之前会有一个非常长的暂停（就 CPU 时钟周期数而言）。在少数情况下，当您从文件中读取时，您可能会获得足够长的延迟，以至于它们变得可被人类感知，甚至可能涉及人为干预。现在已经很少见了，但曾几何时，读取特定文件可能涉及操作员安装磁带等操作。

【讨论】：