This type of question often arises: "On APG pg424 you have a fini() method that closes down a server accept handler, but leaves any established service handlers alone. In fact, it says "Any existing service requests will be allowed to continue, as they have no coupling to the HA_Status object thats being destroyed".

"Now in general, a server will be serving something, so it may be that I want to shut down all the active connections at the same time the acceptor is closed. In that case, you'd have to do more work. In fact, even with the provided example, there is no way to cleanly interrupt a client connection. How would you end the client connections for your example code?"

An excellent question, and one that is often dealt with in real applications that Riverace has consulted on and developed. We laid the ground work for this mechanism in the January 2005 issue of the Riverace News and Tips Newsletter. The steps to follow are:

1. Derive your service-configured acceptor from ACE_Acceptor and reimplement the make_svc_handler() method. Your acceptor class should be created with (or have access to) a control object that will be able to keep track of the active handlers and shut them down. The control can be a member of your acceptor class, so when fini() is called on the acceptor, the acceptor can use the control to find all the active service handlers. It could also be part of the ACE_Service_Object that's actually configured if that's not the acceptor object.
2. The reimplemented make_svc_handler() method instantiates the ACE_Svc_Handler-derived object, passing the control object's pointer/reference to the new handler.
3. The service handler registers itself with the control object, and unregisters itself if it runs down.
4. The ACE_Service_Object's fini() hook iterates over the list of active service handlers, calling their fini() hooks.
5. The service handler's fini() hook takes whatever action is necessary to shut down the handler.

As an example of how to do this, I wrote an expanded version of the APG example referred to above. You can get the source (gzip'd tar file) via the link below. The code doesn't include any serialization for multithreaded access, so you'll need to add this if adapting this approach to a multithreaded environment.

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

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. In particular, the ACE_Dev_Poll_Reactor implementation for Linux would be a great addition. This was mentioned in our March 2005 newsletter - please check it out using the link below for more information!

We're tentatively planning a general-attendance ACE training class for this fall. This is the 3-day "How to Use ACE Effectively" class that's been very well received when given at a number of customer sites. We're looking at having this class in the Boston area (most likely in Waltham) either before or after the SD Best Practices 2005 conference which is in Boston, September 26-29.

Please contact Steve Huston at 888-384-8154 (toll-free in the US) or +1 508-541-9180 with your feedback on whether this date or location is attractive, as well as any other suggestions for other dates that may work better.