反應器（Reactor）：用于事件多路分離和分派的體系結構模式
通常的，對一個文件描述符指定的文件或設備, 有兩種工作方式: 阻塞與非阻塞。所謂阻塞方式的意思是指, 當試圖對該文件描述符進行讀寫時, 如果當時沒有東西可讀,或者暫時不可寫, 程序就進入等待狀態(tài), 直到有東西可讀或者可寫為止。而對于非阻塞狀態(tài), 如果沒有東西可讀, 或者不可寫, 讀寫函數馬上返回, 而不會等待。

在前面的章節(jié)中提到的Tcp通信的例子中，就是采用的阻塞式的工作方式：當接收tcp數據時，如果遠端沒有數據可以讀，則會一直阻塞到讀到需要的數據為止。這種方式的傳輸和傳統(tǒng)的被動方法的調用類似，非常直觀，并且簡單有效，但是同樣也存在一個效率問題，如果你是開發(fā)一個面對著數千個連接的服務器程序，對每一個客戶端都采用阻塞的方式通信，如果存在某個非常耗時的讀寫操作時，其它的客戶端通信將無法響應，效率非常低下。
一種常用做法是：每建立一個Socket連接時，同時創(chuàng)建一個新線程對該Socket進行單獨通信（采用阻塞的方式通信）。這種方式具有很高的響應速度，并且控制起來也很簡單，在連接數較少的時候非常有效，但是如果對每一個連接都產生一個線程的無疑是對系統(tǒng)資源的一種浪費，如果連接數較多將會出現(xiàn)資源不足的情況。
另一種較高效的做法是：服務器端保存一個Socket連接列表，然后對這個列表進行輪詢，如果發(fā)現(xiàn)某個Socket端口上有數據可讀時（讀就緒），則調用該socket連接的相應讀操作；如果發(fā)現(xiàn)某個Socket端口上有數據可寫時（寫就緒），則調用該socket連接的相應寫操作；如果某個端口的Socket連接已經中斷，則調用相應的析構方法關閉該端口。這樣能充分利用服務器資源，效率得到了很大提高。
在Socket編程中就可以通過select等相關API實現(xiàn)這一方式。但直接用這些API控制起來比較麻煩，并且也難以控制和移植，在ACE中可以通過Reactor模式簡化這一開發(fā)過程。

反應器本質上提供一組更高級的編程抽象，簡化了事件驅動的分布式應用的設計和實現(xiàn)。除此而外，反應器還將若干不同種類的事件的多路分離集成到易于使用的API中。特別地，反應器對基于定時器的事件、信號事件、基于I/O端口監(jiān)控的事件和用戶定義的通知進行統(tǒng)一地處理。

ACE中的反應器與若干內部和外部組件協(xié)同工作。其基本概念是反應器框架檢測事件的發(fā)生（通過在OS事件多路分離接口上進行偵聽），并發(fā)出對預登記事件處理器（event handler）對象中的方法的"回調"（callback）。該方法由應用開發(fā)者實現(xiàn)，其中含有應用處理此事件的特定代碼。
使用ACE的反應器，只需如下幾步：
創(chuàng)建事件處理器，以處理他所感興趣的某事件。
在反應器上登記，通知說他有興趣處理某事件，同時傳遞他想要用以處理此事件的事件處理器的指針給反應器。
隨后反應器框架將自動地：
在內部維護一些表，將不同的事件類型與事件處理器對象關聯(lián)起來。
在用戶已登記的某個事件發(fā)生時，反應器發(fā)出對處理器中相應方法的回調。
反應器模式在ACE中被實現(xiàn)為ACE_Reactor類，它提供反應器框架的功能接口。
如上面所提到的，反應器將事件處理器對象作為服務提供者使用。反應器內部記錄某個事件處理器的特定事件的相關回調方法。當這些事件發(fā)生時，反應器會創(chuàng)建這種事件和相應的事件處理器的關聯(lián)。
事件處理器
事件處理器就是需要通過輪詢發(fā)生事件改變的對象列表中的對象，如在上面的例子中就是連接的客戶端，每個客戶端都可以看成一個事件處理器。
回調事件
就是反應器支持的事件，如Socket讀就緒，寫就緒。拿上面的例子來說，如果某個客戶端（事件處理器）在反應器中注冊了讀就緒事件，當客戶端給服務器發(fā)送一條消息的時候，就會觸發(fā)這個客戶端的數據可讀的回調函數。
在反應器框架中，所有應用特有的事件處理器都必須由ACE_Event_Handler的抽象接口類派生?？梢酝ㄟ^重載相應的"handle_"方法實現(xiàn)相關的回調方法。
使用ACE_Reactor基本上有三個步驟：
創(chuàng)建ACE_Event_Handler的子類，并在其中實現(xiàn)適當的"handle_"方法，以處理你想要此事件處理器為之服務的事件類型。
通過調用反應器對象的register_handler()，將你的事件處理器登記到反應器。
在事件發(fā)生時，反應器將自動回調相應的事件處理器對象的適當的handle_"方法。