When programming in an event-driven model, such as with the ACE Reactor framework, the callback nature of event handling can confuse how to handle things like object and memory management. Confusion about managing memory can lead to odd crashes due to memory corruption which are very, very difficult to locate and fix. This article clarifies best practices around managing ACE_Event_Handler memory.

In a number of other articles (August, September, October 2004) we've covered various aspects of using ACE_Svc_Handler that were related to memory management. ACE_Svc_Handler is derived from ACE_Event_Handler and, indeed, ACE_Svc_Handler encapsulates many best practices of event handler management. But situations arise where you can't use the ACE_Svc_Handler-supplied default behaviors, or you may want to use ACE_Event_Handler directly. These situations most often arise in event-driven, not active object, environments. Therefore, all the advice given in this article pertains primarily to reactive, event-driven programming.

Be dynamic. ACE_Event_Handler objects are much easier to manage when allocated dynamically. Using static event handler objects can introduce object lifetime dependencies between your handler's scope and the reactor that make errors very easy to create. And rather hard to diagnose.

Keep It Simple and Central. (Sorry, couldn't figure out an 'S' word for Central ;-) Event-driven programming lacks a nice orderly timeline of execution for you to order object creation in. However, there are specific events which you can use to trigger the needed actions. For example, when accepting a new TCP/IP connection or opening a serial port, that event can trigger allocation and initialization of your ACE_Event_Handler. Similarly, cleanup/deallocation activity should be centralized in your handle_close() callback, providing a central place and a defined event for your cleanup. Don't try to clean things up in multiple places, such as handle_input(), handle_output(), and handle_close().

Clean up and delete in handle_close(). Remember the Reactor-provided structure and order of events. Returning -1 from a callback such as handle_input() will cause the reactor to remove the event that triggered the callback (READ_MASK in handle_input()'s case) and call the handle_close() hook to notify the object that the mask is removed. The handle_close() callback event is the perfect place to centralize cleanup and deallocation. As soon as there are no more event types registered, it's safe to delete the handler. Trying to do it earlier will cause problems, particularly on Windows with the ACE_WFMO_Reactor (see C++NPv2 page 107 for more details on why).

Remembering and adhering to these best practices will greatly improve the robustness of your applications and greatly reduce the time spent debugging odd memory corruption problems. You can read more about these and other aspects of Reactor framework programming in C++NPv2 chapters 3 and 4, as well as APG chapter 7. You can also attend our upcoming How to Use ACE Effectively class, described elsewhere in this newsletter.

The ACE development community is hard at work on the next version of ACE. Here are some of the things you can look forward to (items in bold are new or changed since last month):

• Native library path-searching. Previous ACE versions's implementation of ACE_DLL (used in loading dynamic services) implemented a search of the configured path-search to try and locate the desired library file (DLL) and then used the full pathname to load the library. This skirted some platforms's rules for path search and security settings. This has been changed in the next ACE version to make use of all of the native platform's path-search and security facilities.
• Improved wide-character support. Wide- character support has been included in ACE for many years on Windows (also known as Unicode builds). However, wide-character support for POSIX platforms has been sorely lacking. As ACE's reach expands, this has become a more important issue. Riverace is leading the completion of wide-character support in the next version of ACE. This support is also available now in the ACE 5.4b fix kit.
• GNU autotools support. Riverace is the lead developer in charge of adding auto-configure support to ACE. For native-build, non-Windows systems, autoconf will very likely become the way to configure and build ACE. This will help insure that ACE uses the latest features available on each supported platform, and reduce the work required to build ACE. No more picking the right config.h or platform_macros.GNU file. Just do ./configure then make. Ahhh...
• Support for g++ 4.0, 3.4 and Microsoft Visual C++ 2005 are being added.
• Support for Red Hat Enterprise Linux 4.
• Support for Solaris 10.
• Newer C++ Features Being Used. As the range of ACE-supported compilers matures and older compilers are taken out of service, ACE can make more use of newer C++ features while still maintaining its stellar portability record. For example, many methods that returned 1 or 0 as an int now return bool. Small steps, yes, but significant ones. You'll see more modern C++ usage as time goes on.
• The ACE and ACE_OS classes, previously containing a number of static member functions, are now C++ namespaces. Similar ACE-internal classes, such as ACE_Sock_Connect, are no longer in use.
• Completed ACE_Dev_Poll_Reactor. Sharpcast is sponsoring Riverace's work to complete this important class, enabling use of the new epoll facility on newer Linux kernels. Thanks to Sharpcast's forward-thinking investment in this important class, the entire ACE user community will benefit from the greatly increased scalability of the Reactor framework on Linux.

As you can see, the pace of changes is slowing and the ACE development team is beginning to focus more on testing in preparation for the release of ACE 5.5. The current estimate for ACE 5.5's release is late in 2005, so there's time to get a bit more in.

We've scheduled an open enrollment How to Use ACE Effectively class for October 17-19, 2005 in Waltham, MA (in the Boston area). This is a 3-day class, priced at US$1,250 including continental breakfast, snacks and lunch each day. Each attendee receives a copy of the class slides and a copy of "The ACE Programmer's Guide" (since Steve Huston will be teaching the class, he'll be happy to sign anyone's book).

Attendees also receive a 10% savings on ACE Annual Support purchased when you pay for your class! Take advantage of this opportunity to make the most of your new ACE knowledge and keep the momentum going back at the office with quick answers and direction on your project's issues!