進程接收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而不是阻塞的歷史原因是什麼？

回答

相關問題