【问题标题】:Linux read function implementationLinux读函数实现
【发布时间】:2016-02-21 10:19:37
【问题描述】:

我想知道read() 函数在将套接字描述符传递给它以及将文件描述符传递给它时如何工作。对于文件描述符,它总是返回指定的 n 个字节,如果没有 n 个字节,则返回更少。但是,对于套接字描述符,它没有必要返回 n 个字节。因此,为了确保我们是否收到了 n 个字节,我们必须放置一个应用程序逻辑并记录我们收到的字节数,并在计数为 n。我的问题是,为什么我们在读取文件时不必放置应用程序逻辑?

【问题讨论】:

  • 但是你知道。如果您的文件小于n 怎么办?
  • 好吧,假设我们知道文件的大小。因此,如果我们从文件 desc 中读取这么多字节,它总是会返回这么多字节。但是假设它是一个套接字,我们从中读取了很多字节? @SanderDeDycker
  • 所以你很幸运。它没有被指定为那样的行为,所以你不能依赖它。
  • 如果您希望您的套接字具有类似的行为,请确保它是blocking socket。请注意,尽管忽略read 的返回值仍然不安全,因为它仍然不能保证返回n(由于本地缓冲区中还没有所有数据可用,套接字被关闭,信号中断, ...)

标签: c linux sockets system-calls


【解决方案1】:

阅读read(2) 手册页:

man 2 read

你最好假设它返回的字节数总是少于你传递给它的整个缓冲区(特别是因为很难知道文件描述符是指套接字、tty 还是其他一些设备、管道、fifo 或一些普通文件,还因为您可能拥有一些不符合 POSIX 语义的文件系统)。您也可能已到达文件末尾 (EOF) 等...

对于 TCP 套接字,请记住它们只是字节流,并且可能会在多次读取中接收到给定的单个发送,等等……特别是,消息块可以由“网络”(例如路由器)。

对于普通文件,请记住,在您的进程读取文件时,其他一些进程可能会更改它(例如写入文件、截断文件等)。

【讨论】:

  • 因此即使是读取文件也不能保证返回 n 字节。伟大的。不知道!
  • 首先,你有文件结尾的情况。然后,文件描述符可能不会引用普通文件。最后,一些文件系统可能不符合 POSIX。所以我认为你不应该期待一个坚定的保证,即使在大多数情况下,情况确实如此。请记住,当您阅读文件时,某些其他进程可以修改文件
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-06-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多