python - 为什么父进程的标准输入在关闭 fork 子进程的标准输入文件描述符后仍然接受输入？

Question

fork(2) 我正在运行的 Linux 系统上的手册页说明如下:

The child inherits copies of the parent's set of open file descriptors. Each file descriptor in the child refers to the same open file description (see open(2)) as the corresponding file descriptor in the parent. This means that the two file descriptors share open file status flags, file offset, and signal-driven I/O attributes (see the description of F_SETOWN and F_SET‐SIG in fcntl(2)).

Python 文档提到

_exit() should normally only be used in the child process after a fork().

当然，_exit 不会调用清理处理程序，问题是，如果您查看以下代码:

newpid = os.fork()
if newpid == 0:
    os.close(0)
else:
    time.sleep(.25)
    input()

尽 pipe 进程关闭了标准输入，但父进程仍然接受来自标准输入的输入。很好，这是颠倒过来的代码:

newpid = os.fork()
if newpid == 0:
    input()
else:
    time.sleep(.25)
    os.close(0)

现在，情况正好相反，这次关闭 stdin 的是父进程，而不是子进程。这为子进程中的 input() 调用引发了 EOFError。

这看起来像当 [child] 进程写入/修改父进程的文件描述符时，它不会影响 [parent]。也就是说，子进程获得更新的文件描述。

那么，如果子进程执行的操作不影响父进程，为什么要调用 _exit 作为 Python 文档状态来防止调用清理处理程序？让我们看一下 _EXIT(2) 手册页:

The function _exit() terminates the calling process "immediately". Any open file descriptors belonging to the process are closed; any children of the process are inherited by process 1, init, and the process's parent is sent a SIGCHLD` signal.

The function _exit() is like exit(3), but does not call any functions registered with atexit(3) or on_exit(3). Open stdio(3) streams are not flushed. On the other hand, _exit() does close open file descriptors, and this may cause an unknown delay, waiting for pending output to finish.

fork() 手册页没有提到子进程的清理处理程序是从父进程继承的。这对 parent 有何影响？换句话说，为什么不让子进程自行清理呢？

Answer 1

我假设您是从终端内的 shell 运行它。

shell 在新的进程组中启动 Python 进程，并使用 tcsetpgrp() 将其设置为 TTY 上的前台进程组。

一旦父 Python 进程终止，shell 就会收回对终端的控制(它将自己设置为前台进程组)。 shell 不知道来自 Python 的 fork 子仍在运行。

当不属于前台进程组的进程尝试从终端读取时，它通常会收到 SIGTTIN 信号。然而，在这种情况下，进程组已被孤立，因为它的领导者已经终止，因此子进程从 TTY 上的 read() 得到一个 EIO 错误。 Python 将其视为 EOFError。