Каковы исторические причины процессов, получающих SIGTTYIN/TTOU вместо блокировки?

Question

В unix процесс, запущенный с терминала, может (обычно) не читать или записывать на свой терминал, если он задан. В других случаях, когда процесс не может читать/записывать на свой терминал (или другой дескриптор файла), он просто блокирует и продолжает работать, как только чтение или запись могут быть завершены. В случае процесса, который используется в фоновом режиме, вместо него он получает SIGTTIN или SIGTTOU, который по умолчанию приостанавливает процесс. Если процесс позже перенаправляется, оболочка продолжает его.

Почему такое поведение было таким? Блокировать дескрипторы файлов гораздо проще, чем сигналы, поскольку они часто не требуют специальной обработки вообще. В других случаях, связанных с tty (например, если соединение с терминалом не может обрабатывать скорость передачи данных), процессы просто блокируются. Если процесс должен был знать об этом, он мог бы проверить, был ли он набросок. Были ли в то время какие-либо преимущества для этого дизайна?

Конечно, это поведение теперь является частью posix, поэтому теперь оно фиксируется по «историческим причинам», но каковы были эти исторические причины?

Answer 1

Процессы оболочки появляются, как правило, имеют свой stdin/stdout/stderr, напрямую подключенный к терминалу. Это позволяет процессам делать магические вещи, такие как изменение настроек терминала, шрифтов, режимов ввода клавиатуры и т. Д.

Так что если процессы не приостановлены, они все равно попытаются прочитать входы клавиатуры.

Процессы, которые знает об этой логике, то можно прослушивать сигналы, и отключить ввод/вывод, если фоновый