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

在unix中，从终端启动的进程如果是后台的话，可以（通常）不能读取或写入其终端。在其他情况下，当一个进程无法读/写其终端（或其他文件描述符）时，它只会阻塞，并且一旦完成读或写操作就会继续运行。在后台进程的情况下，它会接收SIGTTIN或SIGTTOU，默认情况下会暂停进程。如果该过程稍后被预先考虑，则壳继续它。进程接收SIGTTYIN/TTOU而不是阻塞的历史原因是什么？

为什么这种行为是这样设计的？阻止文件描述符比信号更容易处理，因为它们通常不需要特殊处理。在涉及ttys的其他情况下（例如，如果到终端的连接不能处理数据速率），这些进程就会阻塞。如果一个过程需要知道这个，它可以检查它是否被预先覆盖。当时那里有这个设计的优点吗？

当然，这种行为现在是posix的一部分，所以现在它是为了“历史原因”而固定的，但是这些历史原因是什么？

来源

2012-02-21 JanKanis

shell产生的进程通常有stdin/stdout/stderr直接连接到终端。这允许进程做更改终端设置，字体，键盘输入模式等神奇的东西。

因此，如果进程没有挂起，他们仍然会尝试读取键盘输入。

流程，知道这个逻辑则可以监听信号，并禁用I /如果转到后台

来源

2016-04-19 11:35:37

这并没有真正回答这个问题O操作。为什么不改用I/O模块呢？ – melpomene 2017-02-21 08:16:57

当多个程序尝试从同一个字符资源读取（处于阻塞模式）时，它将随机（某种程度上）哪个进程接收数据。并以此为例。两个进程都尝试从相同的资源读取。进程A接收其中一个字符，并开始处理它，而处理过程中，进程B接收到第二个字符，因为进程A由于其处理而在短时间内不能读取。 – 2017-03-06 07:36:11

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

回答

相关问题