前幾天學校優秀畢業論文答辯，無意間看到了一個很熟悉的名詞——管道
當時在臺上的是另一個已經簽約在某直播平臺工作的學生，講述的畢業設計好像是說網絡直播通信方面的東西。
我之前在研讀SylixOS應用開發手冊時也看到了這一章節。
其實對於不同的進程間的通信方式，一般有以下幾種：
管道、命名消息隊列、命名信號量、共享內存、信號等
其實我一直覺得，有些難以理解的東西可以放在一個大背景中去了解。
在操作系統設計的初期，應該不會涉及到很多很多的進程間相互通信，只有少數的不同進程通信，那麼信號量則是不二之選，配置簡單，調用方便。
但是隨着操作系統逐步更新換代，信號量顯然變得有些不夠用，並且有的時候很多應用對多個進程重複操作，這時用信號量顯然會變得不可控，此時如果用管道、命名消息隊列就顯然比信號量好很多。
但在在上述解決方法中，管道這種方式僅能對字節流進行承載、並且緩衝區也不可能無限的大，消息隊列，既然是隊列，那麼必然會降低進程通信的實時性。
所以爲了解決上述問題，直接把內存的一塊區域共享出來的方法構思出來，共享內存可以解決實時性的問題（僅限於讀取），這樣便解決了隊列處理的時延。
於是，可以在一個成熟的操作系統源碼當中看到這五種方式其實都同時存在着，在設計其內核時，取其優點，避其缺點。
參考文章：
進程間通信