☰

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

tag-icon • tag-icon file-descriptors fork
为什么文件描述符在分叉进程之间共享？

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

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

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

答案1

考虑一个 shell 片段

{ somecmd; othercommand *.txt; } > outputfile

shelloutputfile在启动重定向时打开一次，然后将文件句柄传递给somecmdand othercmd，处理它fork。考虑到分组，用户期望这两个命令的输出最终都以 结尾outputfile，这可能是正确的，就像它们最终在屏幕上一样。 （如果{ }组是 shell 脚本，情况会是一样的。）

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

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

答案2

POSIX如此解释了推理:

POSIX 程序员调用的原因有两个叉（）。原因之一是在同一个程序中创建一个新的控制线程（这最初只能在 POSIX 中通过创建一个新进程来实现）；另一种是创建一个运行不同程序的新进程。在后一种情况下，调用叉（）很快就会接到一个电话执行功能。

当fork()用作“穷人的线程”时，复制文件描述符是有意义的。该用例必须继续得到支持，因此该功能将保留......

相关内容