Reactor pattern

The reactor design pattern is a concurrent programming 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.

tructure

* Resources: Any resource that can provide input or output to the system.
* Synchronous Event Demultiplexer: Uses an event loop to block on all resources. When it is possible to start a synchronous operation on a resource without blocking, the demultiplexer sends 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 multi threaded 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. Also, due to the synchronous calling of request handlers, the reactor pattern allows for simple coarse-grain concurrency while not adding the complexity of multiple threads to the system.

Limitations

The reactor pattern can be more difficult to debug 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 SMP hardware. The scalability of the reactor pattern is limited not only by calling request handlers synchronously, but also by the demultiplexer. The original Unix select and poll calls for instance have a maximum number of descriptors that may be polled and have performance issues with a high number of descriptors. [Citation
last = Kegel
first = Dan
title = The C10K problem
url=http://www.kegel.com/c10k.html#nb.select
accessdate = 2007-07-28] (More recently, more scalable variants of these interfaces have been made available: /dev/poll in Solaris, epoll in Linux and kqueue/kevent in BSD-based systems, allowing the implementation of very high performance systems with large numbers of open descriptors.)

Implementations

* [http://www.cs.wustl.edu/~schmidt/ACE.html The ADAPTIVE Communication Environment] (C++)
* [http://mina.apache.org/ Apache MINA] (Java)
* POE (Perl)
* Twisted (Python)
* [http://rubyeventmachine.com/pub/rdoc/index.html EventMachine] (Ruby)

References

External links

* [http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events by Douglas C. Schmidt]
* [http://www.ddj.com/cpp/193101548 APR Networking & the Reactor Pattern]