1 / 6

Architectural pattern: Reactor

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

gates
Download Presentation

Architectural pattern: Reactor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  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 • 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.

  4. 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

  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

More Related