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

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

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

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