第四天 程序(process)概念--中

補充一下上一篇的process的運作。其實在早期的瀏覽器都只有一個process，但這有一個很大的風險，如果有其中一個網站發生錯誤，整個瀏覽器都會無法動作。直到Chrome瀏覽器的出現，他有三種不同的process：

1. browser process：管理UI、disk跟network I/O
2. renderer process：負責顯示內容，管理wed page、HTML、Javascript
3. plug-in process：負責外掛程式

其中renderer process是每個網頁都有的，而且他是在sandbox中執行，所以並不會被影響或是影響到外面。

接著說process間的溝通：

在系統中，process可以自己執行或是跟其他的process合作。至於為什麼要跟其他的process合作，是因為可以資料分享、加速計算、模組化跟方便。那process要合作就要透過IPC(interprocess communication) 溝通。IPC有兩種模式：shared memory(部分記憶體共享)跟message passing(訊息溝通)。我們透過producer-consumer problem來解釋這兩種模式，解釋之前先來說明producer-consumer problem。producer-consumer problem顧名思義就是生產者跟消費者間的關係，producer會產生資料放在有限或是無限的buffer中等consumer來消費。

用shared memory來解決的話是用read跟write，producer會把資料放進buffer內(write)，而consumer會去同一個buffer把資料取出來(read)。但是用這個方式，元素資料只能運用到比buffer size小一個的空間。這一切的溝通都是user process在處理的，而在這個機制下最重要的是資料的同步。

用message passing來處理的話是用send跟receive，在溝通前需要在producer跟consumer間建link。而且通訊的方式也分成兩種，直接傳訊息或是間接傳遞。

直接傳的話，就建立link用send跟receive來傳送訊息。而用間接傳遞，就要先建立一個mailbox來放訊息，再透過link處理，同一個mailbox可以有很多的process來連接，而接收完訊息後，mailbox會結束掉。因為一次只能有一個process執行，那當有多個process連接mailbox要做溝通時，就會有限制一次一個process傳送或是接收訊息，或是由系統決定誰接收，收到後再跟傳送者說是誰接收到訊息。

而在間接傳遞的過程中，通訊的同步是非常重要的，所以產生了blocking跟non-blocking的方法存在。如果要blocking，會分成blocking sender或是blocking receiver，blocking sender就是等到receiver收到後才能再送下一個資料; blocking receiver則是收到前一個訊息後才能接收下一個訊息。

那傳送資料時，會運用到的buffer有三種型態：

1. zero capacity：一定要收完之後才能再送，沒有地方給資料排隊。
2. bounded capacity：有限量的空間給資料排隊，若是滿了就必須要等。
3. unbounded capacity：無限的空間給資料，sender可以一直送資料。

到這裡就講完process communication，下一篇會講client-sever system內的溝通。