为什么文件描述符在分叉进程之间共享？

Question

当我们fork()一个进程时，子进程继承了文件描述符。问题是，为什么？

正如我所看到的，当每个进程都试图跟踪 r/w 指针的位置时，共享文件描述符是一件令人头疼的事情。

为什么做出这个设计决定？

Answer 1

考虑一个shell片段

{ somecmd; othercommand *.txt; } > outputfile

shell 打开outputfile一次，在开始重定向时，然后将文件句柄传递给somecmdand othercmd，处理它fork关闭。给定分组，用户可能没有错误地期望两个命令的输出都以 结束outputfile，就像它们最终出现在屏幕上一样。（如果该{ }组是一个 shell 脚本，那将是相同的。）

如果文件位置对于所有进程都是独立的，则 from 的输出othercommand将破坏somecmd. 如果fork重置文件句柄上的位置，shell 将无法传递othercommand指向结尾的句柄outputfile（就像在 之后一样somecmd）。我们必须使用管道来收集两个命令的输出（无论如何它们都是位置不可知的），并让另一个程序连接这两个命令的输出：

{ somecmd; othercommand *.txt } | cat > outputfile

Answer 2

POSIX解释了这样的推理：

\n\n

\n

POSIX 程序员调用fork()有两个原因。原因之一是在同一个程序中创建一个新的控制线程（这最初只能在 POSIX 中通过创建一个新进程来实现）；另一种是创建一个运行不同程序的新进程。在后一种情况下，调用fork()后不久就会调用其中一个exec函数。

\n

\n\n

什么时候fork()用作 \xe2\x80\x9cpoor-man\xe2\x80\x99s 线程\xe2\x80\x9d 时，复制文件描述符是有意义的。该用例必须继续得到支持，因此该功能将保留......

\n