60 likes | 251 Views
Architectural pattern: Reactor. Source: POSA II pp 179 – 214 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
E N D
Architectural pattern: Reactor • Source: POSA II pp 179 – 214 • 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
(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.
Dynamics • Application registers concrete event handlers and the type of events each should handle with the Reactor. • Application invokes the Reactor’s handle_events() method, which starts the “event loop” • Reactor calls the synchronous event demultiplexer. • When events are available, demultiplexer returns to the Reactor. • Reactor determines the appropriate event handler and dispatches the event to it. • Event handler does the work. • Reactor continues at step 3.
Implementation • Define the event handler interface • Dispatch to objects or functions? • Single method or method-per-event-type? • Define the reactor interface • Does the event source come from the handler or the registration call? • Implement the reactor • Includes picking the demultiplexer • Determine the number of reactors required • Implement the concrete event handlers • Includes deciding how to maintain state when needed
Known uses • InterViews • Xt toolkit • ACE Reactor Framework • Several CORBA ORB Core implementations • Call Center management • Non-software: receiving phone calls
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