4.1 Overview

Ru-Brd

The ACE Reactor framework discussed in Chapter 3 presents a real-world example of a framework that's designed for extensibility. The original ACE_Reactor implementation was based solely on the select() synchronous event demultiplexing mechanism. As application requirements and ACE platform support evolved, however, the internal design of the ACE Reactor framework changed to support new application needs and new OS platform capabilities. Fortunately, the ACE_Reactor interface has remained relatively consistent. This stability is important since it simultaneously helps to

• Ensure compatibility with applications written for previous ACE versions

• Allow each application to take advantage of new reactor capabilities as the need arises

This chapter focuses on the most common implementations of the ACE Reactor framework, which are listed in the following table:

ACE Class	Description
ACE_Select_Reactor	Uses the select() synchronous event demultiplexer function to detect I/O and timer events; incorporates orderly handling of POSIX signals.
ACE_TP_Reactor	Uses the Leader/Followers pattern [POSA2] to extend ACE_Select_Reactor event handling to a pool of threads.
ACE_WFMO_Reactor	Uses the Windows WaitForMultipleObjects() event demultiplexer function to detect socket I/O, timeouts, and Windows synchronization events.

ACE also offers other more specialized reactor implementations that are outlined in Section 4.5. The variety of reactor requirements motivating all these reactors grew out of the popular reactive model of networked application design, coupled with:

• The growing popularity and availability of multithreaded systems

• The addition of Windows to ACE's set of supported platforms

• High performance I/O, CPU, and synchronous multiprocessing hardware

• The desire to integrate event handling with GUI frameworks, such as Microsoft Windows, X11 Windows, Trolltech AS's Qt, the Fast Light Toolkit, and TCL/Tk

Newer reactor implementations began by subclassing ACE_Reactor and overriding methods to implement the new capabilities. In 1997, during ACE version 4.4 development, however, the design was changed when ACE user Thomas Jordan suggested use of the Bridge pattern [GoF] for the following reasons:

• The ACE_Reactor interface needed to remain constant to preserve backward compatibility, yet the implementation needed to be flexible and selectable at run time.

• The reactor implementations needed to take advantage of related capability by subclassing where it made sense, yet avoid it completely where it didn't. For example, ACE_TP_Reactor is derived from ACE_Select_Reactor , but ACE_WFMO_Reactor is completely different.

• The expanding set of reactor implementations indicated the need for flexibility to allow further enhancements without changing the ACE_Reactor interface.

Application of the Bridge pattern to the reactor implementations led to the design depicted in Figure 4.1, which shows the major reactor implementations that this chapter discusses. The ACE_Reactor class, which was the original implementation, now plays the Abstraction role in the Bridge pattern. The ACE_Reactor_Impl class plays the Implementor role, and the various user-visible reactor implementations each play a ConcreteImplementor role. The Bridge pattern allows considerable freedom in implementation and allows applications to choose different reactors at run time with minimal impact to existing code.

Figure 4.1. Implementations of the ACE_Reactor Interface

The remainder of this chapter motivates and describes the capabilities of the most common implementations of the ACE_Reactor interface: ACE_Select_Reactor , ACE_TP_Reactor , and ACE_WFMO_Reactor . It explores the detailed design issues associated with these implementations to illustrate the subtleties involved in developing extensible and efficient object-oriented frameworks. It also shows how these reactor implementations can be used to enhance the design of our networked logging server.

Ru-Brd