Linux環境處理序間通訊:管道及有名管道

 　　管道及有名管道

　　在本系列序中作者概述了 linux 處理序間通訊的幾種主要手段。其中管道和有名管道是最早的處理序間通訊機制之一，管道可用於具有親緣關係進程間的通訊，有名管道克服了管道沒有名字的限制，因此，除具有管道所具有的功能外，它還允許無親緣關係進程間的通訊。 認清管道和有名管道的讀寫規則是在程式中應用它們的關鍵，本文在詳細討論了管道和有名管道的通訊機制的基礎上，用執行個體對其讀寫規則進行了程式驗證，這樣做有利於增強讀者對讀寫規則的感性認識，同時也提供了應用範例。

　　1、 管道概述及相關API應用

　　1.1 管道相關的關鍵概念

　　管道是Linux支援的最初Unix IPC形式之一，具有以下特點：

　　管道是半雙工的，資料只能向一個方向流動;需要雙方通訊時，需要建立起兩個管道;

　　只能用於父子進程或者兄弟進程之間(具有親緣關係的進程);

　　單獨構成一種獨立的檔案系統：管道對於管道兩端的進程而言，就是一個檔案，但它不是普通的檔案，它不屬於某種檔案系統，而是自立門戶，單獨構成一種檔案系統，並且只存在與記憶體中。

　　資料的讀出和寫入：一個進程向管道中寫的內容被管道另一端的進程讀出。寫入的內容每次都添加在管道緩衝區的末尾，並且每次都是從緩衝區的頭部讀出資料。

　　1.2管道的建立：

　　#include int pipe(int fd[2])

　　該函數建立的管道的兩端處於一個進程中間，在實際應用中沒有太大意義，因此，一個進程在由pipe()建立管道後，一般再fork一個子進程，然後通過管道實現父子進程間的通訊(因此也不難推出，只要兩個進程中存在親緣關係，這裡的親緣關係指的是具有共同的祖先，都可以採用管道方式來進行通訊)。

　　1.3管道的讀寫規則：

　　管道兩端可分別用描述字fd[0]以及fd[1]來描述，需要注意的是，管道的兩端是固定了任務的。即一端只能用於讀，由描述字fd[0]表示，稱其為管道讀端;另一端則只能用於寫，由描述字fd[1]來表示，稱其為管道寫端。如果試圖從管道寫端讀取資料，或者向管道讀端寫入資料都將導致錯誤發生。一般檔案的I/O函數都可以用於管道，如close、read、write等等。

　　從管道中讀取資料：

　　如果管道的寫端不存在，則認為已經讀到了資料的末尾，讀函數返回的讀出位元組數為0;

　　當管道的寫端存在時，如果請求的位元組數目大於PIPE_BUF，則返回管道中現有的資料位元組數，如果請求的位元組數目不大於PIPE_BUF，則返回管道中現有資料位元組數(此時，管道中資料量小於請求的資料量);或者返回請求的位元組數(此時，管道中資料量不小於請求的資料量)。註：(PIPE_BUF在include/linux/limits.h中定義，不同的核心版本可能會有所不同。Posix.1要求PIPE_BUF至少為512位元組，red hat 7.2中為4096)。

　　關於管道的讀規則驗證：

　　/************** * readtest.c * **************/#include #include

　　向管道中寫入資料：

　　向管道中寫入資料時，linux將不保證寫入的原子性，管道緩衝區一有空閑地區，寫進程就會試圖向管道寫入資料。如果讀進程不讀走管道緩衝區中的資料，那麼寫操作將一直阻塞。

　　註：只有在管道的讀端存在時，向管道中寫入資料才有意義。否則，向管道中寫入資料的進程將收到核心傳來的SIFPIPE訊號，應用程式可以處理該訊號，也可以忽略(預設動作則是應用程式終止)。

　　對管道的寫規則的驗證1：寫端對讀端存在的依賴性

　　#include #include main(){ int pipe_fd[2]; pid_t

　　則輸出結果為： Broken pipe,原因就是該管道以及它的所有fork()產物的讀端都已經被關閉。如果在父進程中保留讀端，即在寫完pipe後，再關閉父進程的讀端，也會正常寫入pipe，讀者可自己驗證一下該結論。因此，在向管道寫入資料時，至少應該存在某一個進程，其中管道讀端沒有被關閉，否則就會出現上述錯誤(管道斷裂,進程收到了SIGPIPE訊號，預設動作是進程終止)

　　對管道的寫規則的驗證2：linux不保證寫管道的原子性驗證

　　#include #include #include main(int argc

　　結論：

　　寫入數目小於4096時寫入是非原子的!

　　如果把父進程中的兩次寫入位元組數都改為5000，則很容易得出下面結論：

　　寫入管道的資料量大於4096位元組時，緩衝區的空閑空間將被寫入資料(補齊)，直到寫完所有資料為止，如果沒有進程讀資料，則一直阻塞。

　　1.4管道應用執行個體：

　　執行個體一：用於shell

　　管道可用於輸入輸出重新導向，它將一個命令的輸出直接定向到另一個命令的輸入。比如，當在某個shell程式(Bourne shell或C shell等)鍵入who│wc -l後，相應shell程式將建立who以及wc兩個進程和這兩個進程間的管道。考慮下面的命令列：

　　$kill -l 運行結果見附一。

　　$kill -l | grep SIGRTMIN 運行結果如下：

　　30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN+134) SIGRTMIN+2 35) SIGRTMIN

　　執行個體二：用於具有親緣關係的處理序間通訊

　　下面例子給出了管道的具體應用，父進程通過管道發送一些命令給子進程，子進程解析命令，並根據命令作相應處理。

　　#include #include main(){ int pipe_fd[2]; pid_t

　　1.5管道的局限性

　　管道的主要局限性正體現在它的特點上：

　　只支援單向資料流;

　　只能用於具有親緣關係的進程之間;

　　沒有名字;

　　管道的緩衝區是有限的(管道制存在於記憶體中，在管道建立時，為緩衝區分配一個頁面大小);

　　管道所傳送的是無格式位元組流，這就要求管道的讀出方和寫入方必須事先約定好資料的格式，比如多少位元組算作一個訊息(或命令、或記錄)等等;

　　2、 有名管道概述及相關API應用

　　2.1 有名管道相關的關鍵概念

　　管道應用的一個重大限制是它沒有名字，因此，只能用於具有親緣關係的處理序間通訊，在有名管道(named pipe或FIFO)提出後，該限制得到了克服。FIFO不同於管道之處在於它提供一個路徑名與之關聯，以FIFO的檔案形式存在於檔案系統中。這樣，即使與FIFO的建立進程不存在親緣關係的進程，只要可以訪問該路徑，就能夠彼此通過FIFO相互連信(能夠訪問該路徑的進程以及FIFO的建立進程之間)，因此，通過FIFO不相關的進程也能交換資料。值得注意的是，FIFO嚴格遵循先進先出(first in first out)，對管道及FIFO的讀總是從開始處返回資料，對它們的寫則把資料添加到末尾。它們不支援諸如lseek()等檔案定位操作。

　　2.2有名管道的建立

　　#include #include int mkfifo(const char * pathname, mode_t mode)

　　該函數的第一個參數是一個普通的路徑名，也就是建立後FIFO的名字。第二個參數與開啟普通檔案的open()函數中的mode 參數相同。如果mkfifo的第一個參數是一個已經存在的路徑名時，會返回EEXIST錯誤，所以一般典型的調用代碼首先會檢查是否返回該錯誤，如果確實返回該錯誤，那麼只要調用開啟FIFO的函數就可以了。一般檔案的I/O函數都可以用於FIFO，如close、read、write等等。

　　2.3有名管道的開啟規則

　　有名管道比管道多了一個開啟操作：open。

　　FIFO的開啟規則：

　　如果當前開啟操作是為讀而開啟FIFO時，若已經有相應進程為寫而開啟該FIFO，則當前開啟操作將成功返回;否則，可能阻塞直到有相應進程為寫而開啟該FIFO(當前開啟操作設定了阻塞標誌);或者，成功返回(當前開啟操作沒有設定阻塞標誌)。

　　如果當前開啟操作是為寫而開啟FIFO時，如果已經有相應進程為讀而開啟該FIFO，則當前開啟操作將成功返回;否則，可能阻塞直到有相應進程為讀而開啟該FIFO(當前開啟操作設定了阻塞標誌);或者，返回ENXIO錯誤(當前開啟操作沒有設定阻塞標誌)。

　　對開啟規則的驗證參見附2。

　　2.4有名管道的讀寫規則

　　從FIFO中讀取資料：

　　約定：如果一個進程為了從FIFO中讀取資料而阻塞開啟FIFO，那麼稱該進程內的讀操作為設定了阻塞標誌的讀操作。

　　如果有進程寫開啟FIFO，且當前FIFO內沒有資料，則對於設定了阻塞標誌的讀操作來說，將一直阻塞。對於沒有設定阻塞標誌讀操作來說則返回-1，當前errno值為EAGAIN，提醒以後再試。

　　對於設定了阻塞標誌的讀操作說，造成阻塞的原因有兩種：當前FIFO內有資料，但有其它進程在讀這些資料;另外就是FIFO內沒有資料。解阻塞的原因則是FIFO中有新的資料寫入，不論信寫入資料量的大小，也不論讀操作請求多少資料量。

　　讀開啟的阻塞標誌只對本進程第一個讀操作施加作用，如果本進程內有多個讀操作序列，則在第一個讀操作被喚醒並完成讀操作後，其它將要執行的讀操作將不再阻塞，即使在執行讀操作時，FIFO中沒有資料也一樣(此時，讀操作返回0)。

　　如果沒有進程寫開啟FIFO，則設定了阻塞標誌的讀操作會阻塞。

　　註：如果FIFO中有資料，則設定了阻塞標誌的讀操作不會因為FIFO中的位元組數小於請求讀的位元組數而阻塞，此時，讀操作會返回FIFO中現有的資料量。

　　向FIFO中寫入資料：

　　約定：如果一個進程為了向FIFO中寫入資料而阻塞開啟FIFO，那麼稱該進程內的寫操作為設定了阻塞標誌的寫操作。

　　對於設定了阻塞標誌的寫操作：

　　當要寫入的資料量不大於PIPE_BUF時，linux將保證寫入的原子性。如果此時管道空閑緩衝區不足以容納要寫入的位元組數，則進入睡眠，直到當緩衝區中能夠容納要寫入的位元組數時，才開始進行一次性寫操作。

　　當要寫入的資料量大於PIPE_BUF時，linux將不再保證寫入的原子性。FIFO緩衝區一有空閑地區，寫進程就會試圖向管道寫入資料，寫操作在寫完所有請求寫的資料後返回。

　　對於沒有設定阻塞標誌的寫操作：

　　當要寫入的資料量大於PIPE_BUF時，linux將不再保證寫入的原子性。在寫滿所有FIFO空閑緩衝區後，寫操作返回。

　　當要寫入的資料量不大於PIPE_BUF時，linux將保證寫入的原子性。如果當前FIFO空閑緩衝區能夠容納請求寫入的位元組數，寫完後成功返回;如果當前FIFO空閑緩衝區不能夠容納請求寫入的位元組數，則返回EAGAIN錯誤，提醒以後再寫;

　　對FIFO讀寫規則的驗證：

　　下面提供了兩個對FIFO的讀寫程式，適當調節程式中的很少地方或者程式的命令列參數就可以對各種FIFO讀寫規則進行驗證。

　　程式1：寫FIFO的程式

　　#include #include #include #include

　　程式應用說明：

　　把讀程式編譯成兩個不同版本：

　　阻塞讀版本:br

　　以及非阻塞讀版本nbr

　　把寫程式編譯成兩個四個版本：

　　非阻塞且請求寫的位元組數大於PIPE_BUF版本：nbwg

　　非阻塞且請求寫的位元組數不大於PIPE_BUF版本：版本nbw

　　阻塞且請求寫的位元組數大於PIPE_BUF版本：bwg

　　阻塞且請求寫的位元組數不大於PIPE_BUF版本：版本bw

　　下面將使用br、nbr、w代替相應程式中的阻塞讀、非阻塞讀

　　驗證阻塞寫操作：

　　當請求寫入的資料量大於PIPE_BUF時的非原子性：

　　nbr 1000

　　bwg

　　當請求寫入的資料量不大於PIPE_BUF時的原子性：

　　nbr 1000

　　bw

　　驗證非阻塞寫操作：

　　當請求寫入的資料量大於PIPE_BUF時的非原子性：

　　nbr 1000

　　nbwg

　　請求寫入的資料量不大於PIPE_BUF時的原子性：

　　nbr 1000

　　nbw

　　不管寫開啟的阻塞標誌是否設定，在請求寫入的位元組數大於4096時，都不保證寫入的原子性。但二者有本質區別：

　　對於阻塞寫來說，寫操作在寫滿FIFO的空閑地區後，會一直等待，直到寫完所有資料為止，請求寫入的資料最終都會寫入FIFO;

　　而非阻塞寫則在寫滿FIFO的空閑地區後，就返回(實際寫入的位元組數)，所以有些資料最終不能夠寫入。

　　對於讀操作的驗證則比較簡單，不再討論。

　　2.5有名管道應用執行個體

　　在驗證了相應的讀寫規則後，應用執行個體似乎就沒有必要了。

　　小結：

　　管道常用於兩個方面：(1)在shell中時常會用到管道(作為輸入輸入的重新導向)，在這種應用方式下，管道的建立對於使用者來說是透明的;(2)用於具有親緣關係的處理序間通訊，使用者自己建立管道，並完成讀寫操作。

　　FIFO可以說是管道的推廣，克服了管道無名字的限制，使得無親緣關係的進程同樣可以採用先進先出的通訊機制進行通訊。

　　管道和FIFO的資料是位元組流，應用程式之間必須事先確定特定的傳輸"協議"，採用傳播具有特定意義的訊息。

　　要靈活應用管道及FIFO，理解它們的讀寫規則是關鍵。

　　附1：kill -l 的運行結果，顯示了當前系統支援的所有訊號：

　　1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL5) SIGTRAP 6) SIGABRT

　　除了在此處用來說明管道應用外，接下來的專題還要對這些訊號分類討論。

　　附2：對FIFO開啟規則的驗證(主要驗證寫開啟對讀開啟的依賴性)