terminal - 进程接收 SIGTTYIN/TTOU 而不是阻塞的历史原因是什么？

Question

在 unix 中，从终端启动的进程在后台运行时(通常)不能读取或写入其终端。在其他情况下，当进程无法读取/写入其终端(或其他文件描述符)时，它只会阻塞，并在读取或写入完成后继续运行。在后台进程的情况下，它会收到 SIGTTIN 或 SIGTTOU，这在默认情况下会暂停进程。如果该进程稍后被置于前台，则 shell 将继续它。

为什么要这样设计这个行为？阻塞文件描述符比信号更容易处理，因为它们通常根本不需要特殊处理。在涉及 ttys 的其他情况下(例如，如果与终端的连接无法处理数据速率)，进程只会阻塞。如果一个进程需要知道这一点，它可以检查它是否被前台处理。这种设计在当时有什么优势吗？

当然，这种行为现在是 posix 的一部分，所以现在由于“历史原因”而被修复，但这些历史原因是什么？

Answer 1

shell 生成的进程通常将它们的 stdin/stdout/stderr 直接连接到终端。这允许进程做一些神奇的事情，比如更改终端设置、字体、键盘输入模式等。

因此，如果进程未挂起，它们仍会尝试读取键盘输入。

了解此逻辑的进程然后可以监听信号，并在后台禁用 I/O