| This chapter described how the most common ACE_Reactor implementations are designed and illustrated some subtle nuances of their different capabilities. In addition to giving some guidelines on when to use each, our discussions emphasized two points: -
Different implementations of OS event demultiplexing mechanisms can present significant challenges, as well as important opportunities. -
A well-designed framework can be extended to use OS capabilities effectively while isolating complex design issues in the framework, rather than in application code. An intelligently designed framework can significantly improve the portability and extensibility of both applications and the framework itself. The ACE Reactor framework implementations are good examples of how applying patterns, such as Wrapper Facade, Facade, and Bridge, and C++ features, such as inheritance and dynamic binding, can yield a high-quality , highly reusable framework with these elusive qualities. The ACE Reactor framework implementations described in this chapter encapsulate many complex capabilities, allowing networked application developers to focus on application-specific concerns. One of the most powerful properties of the ACE Reactor framework design is its ability to enhance extensibility at the following variation points: -
Customized event handlers. It's straightforward to extend application functionality by inheriting from the ACE_Event_Handler class or one of its pre-defined ACE subclasses (such as ACE_Service_Object , ACE_Task ,or ACE_Svc_Handler ) and selectively implementing the necessary virtual method(s). For example, Chapter 7 illustrates how event handlers in our client and server logging daemons can be customized transparently to support authentication. -
Customized ACE_Reactor implementations. It's straightforward to modify the underlying event demultiplexing mechanism of an ACE_Reactor without affecting existing application code. For example, porting a reactive logging server from a UNIX platform to a Windows platform requires no visible changes to application code. In contrast, porting a C implementation of the server from select() to WaitForMultipleObjects() is tedious and error-prone . Over the previous decade , ACE's use in new environments has yielded new requirements for event-driven application support. For example, GUI integration is an important area due to new GUI toolkits and event loop requirements. The following new Reactor implementations were made easier due to the ACE Reactor framework's modular design: | ACE Class | Description | | ACE_Dev_Poll_Reactor | Uses the /dev/poll or /dev/epoll demultiplexer . It's designed to be more scalable than select() -based reactors. | | ACE_Priority_Reactor | Dispatches events in developer-assigned priority order. | | ACE_XtReactor | Integrates ACE with the X11 Toolkit. | | ACE_FlReactor | Integrates ACE with the Fast Light (FL) GUI framework. | | ACE_QtReactor | Integrates ACE with the Qt GUI toolkit. | | ACE_TkReactor | Integrates ACE with the TCL/Tk GUI toolkit. | | ACE_Msg_WFMO_Reactor | Adds Windows message handling to ACE_WFMO_Reactor . | You can read about these reactors in the ACE documentation at http://ace.ece.uci.edu/Doxygen/ or http://www.riverace.com/docs/. |
