Reactor and Proactor Pattern

The Reactor pattern offers the following benefits:

Separation of concerns

The Reactor pattern decouples application-independent demultiplexing and dispatching mechanisms from application-specific hook method functionality. The application-independent mechanisms can be designed as reusable components that know how to demultiplex indication events and dispatch the appropriate hook methods defined by event handlers. Conversely, the application-specific functionality in a hook method knows how to perform a particular type of service.

Modularity, reusability, and configurability

The pattern decouples event-driven application functionality into several components. For example, connection-oriented services can be decomposed into two components: one for establishing connections and another for receiving and processing data.

Portability

UNIX platforms offer two synchronous event demultiplexing functions, select() and poll(), whereas on Win32 platforms the WaitForMultipleObjects() or select() functions can be used to demultiplex events synchronously. By decoupling the reactor's interface from the lowerlevel operating system synchronous event demultiplexing functions used in its implementation, the Reactor pattern therefore enables applications to be ported more readily across platforms.

Coarse-grained concurrency control

Reactor pattern implementations serialize the invocation of event handlers at the level of event demultiplexing and dispatching within an application process or thread. This coarse-grained concurrency control can eliminate the need for more complicated synchronization within an application process.

The Reactor pattern can also incur the following liabilities:

Restricted applicability

The Reactor pattern can be applied most efficiently if the operating system supports synchronous event demultiplexing on handle sets. If the operating system does not provide this support, however, it is possible to emulate the semantics of the Reactor pattern using multiple threads within the reactor implementation. This is possible, for example, by associating one thread to process each handle.

Non-pre-emptive

In a single-threaded application, concrete event handlers that borrow the thread of their reactor can run to completion and prevent the reactor from dispatching other event handlers. In general, therefore, an event handler should not perform long duration operations, such as blocking I/O on an individual handle, because this can block the entire process and impede the reactor's responsiveness to clients connected to other handles.

Complexity of debugging and testing

It can be hard to debug applications structured using the Reactor pattern due to its inverted flow of control. In this pattern control oscillates between the framework infrastructure and the method call-backs on application-specific event handlers. The Reactor's inversion of control increases the difficulty of 'single-stepping' through the run-time behavior of a reactive framework within a debugger, because application developers may not understand or have access to the framework code.

参考：Pattern-Oriented Software Architecture Volume 2, Patterns for Concurrent and Networked Objects, 3.1 Reactor

下面通过一个高性能 Web 服务器实例来说明 Proactor 模式。

当用户要从指定的 URL 下载内容时，有下面 4 个步骤：
(1) 浏览器与 URL 指定的 Web 服务器建立连接连接，然后向它发送 HTTP GET 请求。
(2) Web 服务器接收浏览器的 CONNECT 指示，接受连接，读取并解析请求。
(3) 服务器打开并读取指定的文件。
(4) 最后，服务器将文件的内容发回给 Web 浏览器，并关闭连接。

上面 4 个基本步骤如图 1 所示。

这个实例摘自：Proactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events

Completion ports in Windows NT is the mechanisms to implement the Proactor pattern efficiently in Windows System. On some real-time POSIX platforms the Proactor pattern is implemented by the aio_*() family of APIs.

The Proactor pattern offers the following benefits:

Separation of concerns

The Proactor pattern decouples application-independent asynchronous mechanisms from application-specific functionality. The applicationindependent mechanisms become reusable components that know how to demultiplex the completion events associated with asynchronous operations and dispatch the appropriate callback methods defined by concrete completion handlers. Similarly, the application-specific functionality in concrete completion handlers know how to perform particular types of service, such as HTTP processing.

Portability

The Proactor pattern improves application portability by allowing its interface to be reused independently of the underlying operating system calls that perform event demultiplexing. For example, on real-time POSIX platforms the asynchronous I/O functions are provided by the aio_*() family of APIs. Similarly, on Windows NT, completion ports and overlapped I/O are used to implement asynchronous I/O.

Encapsulation of concurrency mechanisms

A benefit of decoupling the proactor from the asynchronous operation processor is that applications can configure proactors with various concurrency strategies without affecting other application components and services.

Decoupling of threading from concurrency

The asynchronous operation processor executes potentially long-duration operations on behalf of initiators. Applications therefore do not need to spawn many threads to increase concurrency. This allows an application to vary its concurrency policy independently of its threading policy. For instance, a Web server may only want to allot one thread per CPU, but may want to service a higher number of clients simultaneously via asynchronous I/O.

Performance

Multi-threaded operating systems use context switching to cycle through multiple threads of control. While the time to perform a context switch remains fairly constant, the total time to cycle through a large number of threads can degrade application performance significantly if the operating system switches context to an idle thread. For example, threads may poll the operating system for completion status, which is inefficient. The Proactor pattern can avoid the cost of context switching by activating only those logical threads of control that have events to process. If no GET request is pending, for example, a Web server need not activate an HTTP Handler.

Simplification of application synchronization

As long as concrete completion handlers do not spawn additional threads of control, application logic can be written with little or no concern for synchronization issues. Concrete completion handlers can be written as if they existed in a conventional single-threaded environment. For example, a Web server's HTTP handler can access the disk through an asynchronous operation, such as the Windows NT TransmitFile() function , hence no additional threads need to be spawned.

The Proactor pattern has the following liabilities:

Restricted applicability

The Proactor pattern can be applied most efficiently if the operating system supports asynchronous operations natively. If the operating system does not provide this support, however, it is possible to emulate the semantics of the Proactor pattern using multiple threads within the proactor implementation. This can be achieved, for example, by allocating a pool of threads to process asynchronous operations. This design is not as efficient as native operating system support, however, because it increases synchronization and context switching overhead without necessarily enhancing application-level parallelism.

Complexity of programming, debugging and testing

It is hard to program applications and higher-level system services using asynchrony mechanisms, due to the separation in time and space between operation invocation and completion.

Scheduling, controlling, and canceling asynchronously running operations

Initiators may be unable to control the scheduling order in which asynchronous operations are executed by an asynchronous operation processor.

参考：Pattern-Oriented Software Architecture Volume 2, Patterns for Concurrent and Networked Objects, 3.2 Proactor

Reactor 模式里，操作系统只负责通知 I/O 就绪，具体的 I/O 操作（例如读写）仍然是要在业务进程里阻塞的去做的，而 Proactor 模式则更进一步，由操作系统将 I/O 操作执行好（例如读取，会将数据直接读到内存 buffer 中），而 handler 只负责处理自己的逻辑，真正做到了I/O与程序处理异步执行。所以我们一般又说“Reactor是同步I/O，Proactor是异步I/O”。

参考：Netty那点事（四）Netty与Reactor模式