Reactor pattern Beginning
The Reactor pattern has been introduced in [Schmidt95] as a general architecture for event-driven systems. It explains how to register handlers for particular event types, and how to activate handlers when events occur, even when events come from multiple sources, in a single-threaded environment. In other words, the reactor allows for the combination of multiple event-loops, without introducing additional threads.
The Reactor pattern
- activate handlers when events occur
- allow events from multiple sources
- in single threaded process
See D.C. Schmidt, Using Design Patterns to Develop Reusable Object-oriented Communication Software, CACM October '95, 38(10): 65-74
slide: The Reactor pattern
The abstract layout of the software architecture needed to realize the pattern is depicted in slide reactor-structure. The reactor environment must allow for binding handlers to particular types of events. In addition, it must be able to receive events, and select a handler to which the event can be dispatched.
slide: The Reactor pattern -- structure
Events may be organized in a hierarchy. There are two possible choices here. Either the topmost event class has a fat interface, containing all the methods that an event may ever need to support, or the topmost event class can be lean, so that additional methods need to be added by the subclasses of event. The first solution is chosen for hush, because in C++ it is not possible to load new classes dynamically. The latter solution is the way Java does it. In Java new event types can be added at the reactor level without recompiling the system. In the Java AWT and Swing libraries, handlers are called Listeners.
Concrete handlers, derived from an abstract handler, must provide a method, such as operate(Event) that can be called by the reactor when the handler is selected after receiving an event.
slide: The Reactor Pattern - interaction
The interaction between the application, its handlers, the reactor and the environment from which the events originate is depicted in slide reactor-interaction. First, the reactor must be initialized, then one or more handlers can be registered, providing a binding for particular types of events. The reactor must then start to execute its eventloop. When it receives an event from the environment, it selects a handler and dispatches the event to that handler, by calling operate(Event).
Consequences
Modularity is one of the advantages of an event-driven software architecture. Handlers can be composed easily, since their invocation is controlled by the reactor. Another advantage is the decoupling of application-independent mechanisms from application-specific policies. In other words, handler objects need not be aware of how events are dispatched. This is the responsibility of the system or framework.
The fact that control is handed over to the environment has, however, also some disadvantages. First of all, as experience with student assignments shows, it is difficult to learn in the beginning. But even when mastered, applications may be hard to debug, since it is not always clear why a particular handler was invoked, and because it may be difficult to repeat the computation preceding the fault.
Applicability
Some variant of the reactor pattern is used in Unix (X) Windows, (MS) Windows, and also GUI libraries such as Interviews, ET++ and hush. Another example is the Orbacus object request broker, that supports a reactor mode for server objects, which allows for receiving messages from multiple sources in a single thread. The Orbacus broker, however, also allows for multi-threaded servers.