Каковы исторические причины для процессов, получающих SIGTTYIN / TTOU вместо блокировки? - PullRequest
3 голосов
/ 22 февраля 2012

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

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

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

1 Ответ

0 голосов
/ 19 апреля 2016

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

Поэтому, если процессы не приостановлены, они все равно будут пытаться прочитать ввод с клавиатуры.

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

...