为什么在 UNIX 中只分配最低的可用文件描述符？

Question

在一次小组讨论中，我对这个问题很感兴趣——

为什么 UNIX 标准要求保证只为进程分配最低的可用文件描述符？

我能想到的唯一可能的答案是可扩展性。由于我们总是选择最不可用的描述符，描述符位图的使用部分大部分是密集的，因此数组的增长较慢。

我只是想知道是否还有其他我不知道的原因。

此外，如果我们知道给定的描述符比另一个更大/更小，我们是否有一些可以得出逻辑结论（我们可以在程序中使用的结论）的场景。我的理解虽然不允许使用这种技术，因为它不能保证描述符的年龄。

Answer 1

原因有很多，但最终的一个是“因为它一直都是这样做的”。

传统上，进程的文件描述符表是固定大小的，而且非常小（第 7 版 Unix，IIRC 中为 20）。

确定性机制对于 shell 中的 I/O 重定向至关重要。例如：

cat file1 file2 > file3

shell 需要将标准输出重定向到file3. 因此，它可以使用：

close(1);  // Standard output
if (open("file3", O_WRONLY|O_CREAT, 0666) != 1)
   …error creating file…

它会知道因为标准输入已经打开（文件描述符 0），所以open()将返回文件描述符 1。

如今，您无法从文件描述符值中推断出任何内容。我可以写：

int fd1 = open(filename, flags, mode);
int fd2 = dup2(fd1, 1024);
close(fd1);

并且fd2（应该）包含 1024的事实并没有告诉您与文件描述符 3（可能会在下一次open()调用中返回）相比它的打开顺序的任何信息。