linux的rpc是作為nfs的底層支援介面放在核心中的。當然，需要的話，其他模組也能呼叫rpc介面。
為了高效的排程各個rpc請求，linux的prc排程實際上是乙個事件驅動模型。c/s結構，大多使用多程序服務模型，這種模型的優點是程式設計簡單，因為作業系統都是基於程序排程的，可以直接使用作業系統的介面。缺點是不適用於大規模的服務。服務程序或者執行緒的數目越多，用於切換排程的開銷就越多，一旦程序或者執行緒的個數超過一定值，系統就會變的響應異常緩慢。而事件驅動模型正好相反，由於缺乏通用的事件排程介面，只有全部由自己實現，但是不管遇到多少數量的服務，都不會在切換上花費太多開銷。
為了沒有切換開銷，簡單點當然是完全由乙個程序單幹。更高階的做法是每個處理器乙個程序，同時跑，多徹底。核心裡面的工作佇列機制實際上就是這樣幹的，因此rpc對於非同步處理的排程就是使用的工作佇列的介面。
rpc在乙個函式中處理了同步和非同步兩種情況。事實上，如果是同步情況，則會在該函式中睡眠，直到醒來的條件滿足。如果是非同步情況，則處理完後會直接返回，任務的睡眠和後續啟動由專門的非同步機制，也就是工作佇列來完成。
函式__rpc_excute()對任何rpc請求一視同仁。其步驟如下：
無限迴圈
處理完成後的收尾工作
非同步rpc則由rpc_async_schedule（）函式通過工作佇列機制被呼叫，該函式內主要是__rpc_excute()
附1 工作佇列的介紹
1。預設情況下核心只有名字為event的一類工作佇列，這一類工作佇列在每個cpu上都有乙個核心執行緒。rpc新建了一類，取名為rpciod工作佇列。
wq = create_workqueue("rpciod");
if (wq == null)
rpciod_workqueue = wq;
2。隨後沒個rpc任務初始化時候都會有
task->tk_workqueue = rpciod_workqueue;
3。當乙個task啟動時候，如果是非同步的，便啟動函式rpc_async_schedule（）作為非同步rpc請求的處理函式。
init_work(&task->u.tk_work, rpc_async_schedule, (void *)task);
status = queue_work(task->tk_workqueue, &task->u.tk_work);
一種Handle結構
最近看到了這樣一篇部落格，感覺寫的很好。尤其是它其中敘述的這種基於事件的模型。我也是照貓畫虎的寫了個示例程式，不知道對不對我斗膽描述一下這個結構 1.定義乙個介面，定義需要提供的服務。2.定義乙個抽象類 或者普通的類 實現上述介面，實現介面的所有服務，實現內容都為空的。3.接下來，使用者可以根據自己...
比較方便的一種點選事件處理
1 button 2android id id button1 3android layout width wrap content 4android layout height wrap content 5android onclick onclick 6android text button1 ...
C 事件 事件本身就是一種多播委託
c 中的事件就是委託的乙個變數。它和屬性 方法一樣，都是類的成員。只不過事件是指向乙個方法，當事件被觸發時，就會執行物件的相關方法。事件的這種對方法的引用並不是寫死在 裡面的，而是可以進行更改的。闢如 我們在dotnet中按鈕的onclick事件，它可以指向符合onclick事件簽名的任何乙個方法。...