1. Architectural pattern: Reactor Source: POSA II pp 179 – 214POSA II Environment: an application that receives multiple requests simultaneously but may process them synchronously and serially Problem: –Application cannot block, waiting for requests from one client and starve the others –Application cannot afford thread-per-client

2. (Core of a) solution - reactors Event handler knows how to process events (such as session start, service request) related to the application. Event handlers register with the Reactor. Reactor manages registered event handlers and handles (operating-system supplied handles). When an event arrives, the Reactor dispatches it to the appropriate event handler. Synchronous event demultiplexer waits for events to occur, and notifies the Reactor when there are events ready for processing. Examples: select() in UNIX, WaitForMultipleObjects() in Win32.

3. Dynamics 1.Application registers concrete event handlers and the type of events each should handle with the Reactor. 2.Application invokes the Reactor’s handle_events() method, which starts the “event loop” 3.Reactor calls the synchronous event demultiplexer. 4.When events are available, demultiplexer returns to the Reactor. 5.Reactor determines the appropriate event handler and dispatches the event to it. 6.Event handler does the work. 7.Reactor continues at step 3.

4. Implementation 1.Define the event handler interface Dispatch to objects or functions? Single method or method-per-event-type? 2.Define the reactor interface Does the event source come from the handler or the registration call? 3.Implement the reactor Includes picking the demultiplexer 4.Determine the number of reactors required 5.Implement the concrete event handlers Includes deciding how to maintain state when needed

5. Known uses InterViews Xt toolkit ACE Reactor Framework Several CORBA ORB Core implementations Call Center management Non-software: receiving phone calls

6. Consequences Benefits –Separation of concerns –Modularity, reusability, configurability –Portability –Concurrency control (coarse grained) Liabilities –Restricted applicability (requires select() or equivalent) –Non-preemptive –Complexity in testing and debugging