Reactor pattern

This article relies largely or entirely on a single source. Relevant discussion may be found on the talk page. Please help by introducing citations to additional sources. Find sources:  –  ·  ·  · scholar · JSTOR (July 2012)

The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.^[1]

Structure[]

Resources

Any resource that can provide input to or consume output from the system.

Synchronous Event Demultiplexer

Uses an event loop to block on all resources. The demultiplexer sends the resource to the dispatcher when it is possible to start a synchronous operation on a resource without blocking (Example: a synchronous call to read() will block if there is no data to read. The demultiplexer uses select() on the resource, which blocks until the resource is available for reading. In this case, a synchronous call to read() won't block, and the demultiplexer can send the resource to the dispatcher.)

Dispatcher

Handles registering and unregistering of request handlers. Dispatches resources from the demultiplexer to the associated request handler.

Request Handler

An application defined request handler and its associated resource.

Properties[]

All reactor systems are single-threaded by definition, but can exist in a multithreaded environment.

Benefits[]

The reactor pattern completely separates application-specific code from the reactor implementation, which means that application components can be divided into modular, reusable parts.

Limitations[]

The reactor pattern can be more difficult to debug^[2] than a procedural pattern due to the inverted flow of control. Also, by only calling request handlers synchronously, the reactor pattern limits maximum concurrency, especially on symmetric multiprocessing hardware. The scalability of the reactor pattern is limited not only by calling request handlers synchronously, but also by the demultiplexer.^[3]

See also[]

• Proactor pattern (a pattern that also demultiplexes and dispatches events, but asynchronously)
• Application server
• C10k problem

References[]

External links[]

• An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events by Douglas C. Schmidt
• APR Networking & the Reactor Pattern
• Architecture of a Highly Scalable NIO-Based Server
• Akka's I/O Layer Architecture