先前的EOF之后，从管道中阅读会产生更多数据吗？
如果您是从常规文件中读取，并且它返回0，因为您必须使用EOF，但是其他人将某些内容附加到文件中，那么随后的读 syscall将会给您新数据。同样，如果您读取从TTY读取，并且它返回0，因为用户点击Ctrl+d，但是用户键入更多文本，则随后的read> read Syscall将为您提供新数据。但是，如果您阅读是从管道上读取呢？一个读取 syscall是否可以返回0，然后以后的一个人会从管道中获取更多数据？
If you're reading from a regular file, and it returns 0 because you got to EOF, but then someone else appends something to the file, a subsequent read syscall will give you the new data. Similarly, if you're reading from a TTY, and it returns 0 because the user hit Ctrl+D, but then the user types some more text, a subsequent read syscall will give you the new data. But what about if you're reading from a pipe? Is it ever possible that one read syscall could return 0, and that a later one would then get more data out of a pipe?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的。
在同一FD上读取，如果某些内容重新打开了撰写管道，则将再次开始返回数据。您可以轻松地重新打开命名管道，Linux可以通过写入
/proc/＆lt; pid＆gt;/fd/fd/＆lt; fd＆gt;来重新打开匿名管道。特别是，即使FD仅在您从中获取的过程中读取，您也可以打开此文件以供编写。Yes.
readon the same FD will start returning data again if something reopens the pipe for writing.You can easily reopen named pipes, and Linux lets you reopen anonymous pipes by writing to
/proc/<pid>/fd/<fd>. In particular, you can open this file for writing even if the FD is only open for reading in the process that you're getting it from.如果您尝试读取内部未命名的pipe，并且没有数据默认情况下读者会停滞不前。
如果作者关闭管道，则读者将没有数据返回，但是现在管道已关闭。没有人可以写。如果作者重复了，读者将停滞不前，直到所有作者都关闭（默认情况下）。
您可以通过FCNTL F_SETFL将管道模式设置为O_NONBLOCK，但是如果当前没有可用的内容，则调用此返回返回失败代码Eagain或EwoldBlock（我的Linux上相同？）。
如果管道实际上是命名pipe = fifo，则IE作为常规路径文件打开，该文件以前是使用mkfifo（）创建的，然后读取器再次仅块或返回eagain。如果没有作家，或者作者只是没有输出，它将阻止它。
请注意，如果有 /不 /作者，只需打开（）fifo供读取，直到有作家，即使没有写入内容。在内部，有记录在至少有1个读者和1个作家（或O_NonBlock）之前，没有创建管道。但是，用O_NONBLOCK打开FIFO读取总是成功的，因此您不知道是否有任何作家。
因此，FIFO阅读器没有任何简单的方法可以知道是否没有作家。您可能可以向停滞的封锁开放式阅读发射信号吗？
我不确定如果文件未链接（已删除）并且没有作家会发生什么。也许这会触发EOF？或者，也许您的代码会等待，因为现在无法添加更多作家？
If you try to read an internal unnamed-pipe and there is no data the reader will stall by default.
If the writer closes the pipe then the reader will return with no data, but now the pipe is closed. Nobody can write. If the writer duplicated, the the reader will stall until all writers are closed (by default).
You can set the pipe mode to O_NONBLOCK via fcntl F_SETFL, but then calling this returns a fail code EAGAIN or EWOULDBLOCK (the same on my linux?) if there is currently no content available.
If the pipe is actually a named-pipe = fifo, i.e. opened as a regular path file that was previously created with mkfifo(), then again the reader just blocks or returns EAGAIN. It will block if there are no writers, or if the writer(s) are just not outputting.
Note that just open()ing fifo for read will block if there are /no/ writers, until there is a writer, even if there is no content written. Internally, it is documented that the pipe is not created until there is at least 1 reader and 1 writer (or O_NONBLOCK). But opening fifo read with O_NONBLOCK always succeeds, so you don't know if there are any writers or not.
So there is no easy documented way for a fifo reader to know if there are no writers. You could perhaps fire a signal at the stalled blocking open-for-read?
I'm not sure what happens if the file is unlinked (deleted) and there are no writers. Perhaps that triggers an EOF? Or perhaps your code will wait for ever, as it is now not possible to add more writers?