我有两个进程，一个是写入（追加）到一个文件，另一个是读取它。两个进程同时运行，但不通信。另一个读取器进程可能会在写入器进程完成之前启动。
这种方法有效，但 read() 通常返回读取零字节且没有错误。它们的零长度读取与非零长度读取的比率很高，这是低效的。
有没有办法解决这个问题？这是在 POSIX 文件系统上。
【问题讨论】：
pipe 的原因。读取零字节是所有 UNIX 系统中正常的文件结尾检测机制，因此您可以改用命名管道。
标签： linux file filesystems posix
如果没有通信通道，则无法保证在读取正在写入的文件时防止零字节读取甚至长时间挂起而不读取任何数据。 tail 的 Linux 实现使用 inotify 有效地创建通信通道并获取有关文件写入活动的信息。
这是一个非常有趣的问题，IBM 甚至 published a Redbook 描述了一种能够以大约 15 GB/秒的速度执行这种“后读后写”的实现：
Read-behind-write 是一些高端客户使用的一种技术 降低延迟并提高性能。读后写技术 意味着一旦作者开始写作，读者就会 立即跟踪阅读；这个想法是重叠写 时间与阅读时间。这个概念对速度慢的机器很有用 输入/输出性能。对于高 I/O 吞吐量机器，例如 pSeries 690，可能值得考虑先将整个文件写入 并行，然后并行读取数据。
有很多方法可以实现后写。在里面 Xdd实现的方案，写入器写入一条记录后， 等待读者阅读该记录，然后作者才能继续。 尽管这种方案使写入器和读取器保持同步，但只有一个 记录分开，它需要系统时间来做锁定和 作家和读者之间的同步。
如果一个人不关心读者落后了多少条记录 编写器，然后可以实现编写器流式传输的方案 尽可能快地写下来。作者可以更新一个全局 写入一定数量的记录后的变量。读者可以 然后拉出全局变量以找出它需要多少条记录 阅读。
如果没有通信渠道，您几乎不得不继续尝试，可能会在多个零字节 read() 结果之后调用sleep() 或类似的东西。
【讨论】：