Happy New Year! Welcome to the January 2005 edition of Riverace's ACE News and Tips newsletter. This issue contains a helpful review of how to customize the ACE_Acceptor class to create new service handlers in a specialized way, news about what's coming up in the next ACE release, and a note about the latest ACE Fix Kit releases.

Please forward this newsletter to anyone you think may be interested! Anyone who wishes to receive their own copy of this newsletter can subscribe at http://www.riverace.com/subscribe2/index.mv. If you no longer wish to subscribe, removal directions are at the bottom of this page.

Please reply with any feedback you have on this newsletter, as well as ideas for information you'd like to see in upcoming newsletters. We want to be as helpful as possible, so please let us know how we can do that.

ACE Tip: Customizing Service Handler Creation in ACE_Acceptor

The ACE_Acceptor class facilitates the listening for new connections to a service, and the creation and activation of a ACE_Svc_Handler-derived class for each new connection to the service. In the August 2004 edition of the newsletter we looked at the ACE_Svc_Handler::open() hook and its role in initializing a service handler. In this article we back up a few steps to see how the service handler is instantiated and how we can customize that behavior.

Recall that ACE_Acceptor is a class template and that the first template argument to ACE_Acceptor is the class representing the service handler for each new connected service. When a new connection is made to the address the ACE_Acceptor is waiting on, ACE_Acceptor calls its make_svc_handler() hook method to actually create the new service handler object. The implementation of ACE_Acceptor::make_svc_handler() is shown below:

template <class SVC_HANDLER, ACE_PEER_ACCEPTOR_1> int
ACE_Acceptor<SVC_HANDLER, ACE_PEER_ACCEPTOR_2>::make_svc_handler (SVC_HANDLER *&sh)
{
  ACE_TRACE ("ACE_Acceptor<SVC_HANDLER, ACE_PEER_ACCEPTOR_2>::make_svc_handler");

  if (sh == 0)
    ACE_NEW_RETURN (sh,
                    SVC_HANDLER,
                    -1);

  // Set the reactor of the newly created <SVC_HANDLER> to the same
  // reactor that this <ACE_Acceptor> is using.
  sh->reactor (this->reactor ());
  return 0;
}
       

The two primary steps taken by the default implementation are:

1. Obtain a new SVC_HANDLER, in this case by allocating one using operator new.
2. Set the new service handler's reactor pointer to the reactor that the ACE_Acceptor is using.

However, what if an application requires obtaining a SVC_HANDLER object in some other way than dynamic allocation using the default constructor? For example, we may need to:

• Obtain a SVC_HANDLER from a preallocated pool.
• Pass some information to the new SVC_HANDLER.
• Use a singleton SVC_HANDLER.

For cases such as these we can customize the make_svc_handler() hook to implement the necessary behavior. For example, let's say our new handlers need to have a pointer to a central processor for all messages that the service handler receives. The processor is represented by a Processor class, and each new handler requires a pointer to the central Processor class. Rather than keep a globally-accessible pointer to a Processor, we can derive a new class from ACE_Acceptor that has the Processor pointer and passes it to each new service handler.

The new acceptor class could be defined thusly:

class My_Acceptor : public ACE_Acceptor<Service, ACE_SOCK_ACCEPTOR>
{
public:
  My_Acceptor (Processor *processor) : processor_ (processor) { };
  
  int make_svc_handler (Service *&sh)
    {
      if (sh == 0)
        ACE_NEW_RETURN (sh,
                        Service (this->processor_),
                        -1);

      // Set the reactor of the newly created <SVC_HANDLER> to the same
      //  reactor that this <ACE_Acceptor> is using.
      sh->reactor (this->reactor ());
      return 0;
    }

private:
  Processor *processor_;
}

That's it. Now, when My_Acceptor accepts a new connection for the service, the make_svc_handler() hook allocates a new Service, passing the Processor* to it. Note that although the Service(Processor*) constructor is used, Service must still define a default constructor to satisfy the template requirements of ACE_Acceptor.

Section 7.3 in C++NPv2 discusses the entire sequence of steps involved in ACE_Acceptor's acceptance sequence. If you have more questions about this aspect of the ACE Acceptor-Connector framework, please feel free to file a support request to get further clarification and information. If you're not a Riverace support customer, you can learn more about our support services at http://www.riverace.com/support.htm.

ACE.next: What's New?

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...
• New compiler support. Support for g++ 3.4 and Microsoft Visual C++ 2005 are being added.
• 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.

New ACE Fix Kits Released!

Riverace released ACE versions 5.3e and 5.4b, containing lots of new fixes and improvements to the ACE 5.3 and 5.4 release series, respectively. These kits provide fixes to previously released ACE versions, and are not beta test kits in the ACE develoment stream. The small price for these kits provides you with tremendous value in the ability to maintain stability in your projects while picking up important fixes to ACE.

New Project Coming Up?

If you're planning a new project to start soon, or find yourself grappling with how to apply ACE to your current project, remember that Riverace provides world-class development and consulting services with special expertise in ACE. We can help you be sure that your new system is designed to take full advantage of ACE's power and flexibility, getting your system delivered in the shortest possible time and with the highest level of quality. Please contact Steve Huston at 888-384-8154 (toll-free in the US) or +1 508-541-9180 to discuss how Riverace can help you.

Useful ACE Information

• Riverace-supported ACE Releases (don't forget, ACE Annual Support customers get no-charge access to all Fix Kits!)

• ACE Books are available via riverace.com from amazon.com
• Looking for ACE reference documentation? Please see www.riverace.com/docs.htm
• Need more help? Riverace is the premier support provider for ACE. We also offer hands-on design and consulting services to help you get the most out of ACE's power and flexibility.

Quotables

"I also wanted to take this opportunity to express my appreciation for the quality and responsiveness of your organization.  It is a very rare pleasure to work with an organization that provides in-depth technical support while remaining strongly customer focused - a fact you clearly demonstrate on every interaction.  With your help, we have been able to dramatically improve our development schedule while reducing the overall cost and resources required.  Riverace has exceeded our expectations without exception."

Christopher W. Midgley
Chief Technology Officer
LiveVault Corporation

This Newsletter...

... is produced by Riverace Corporation to educate the ACE user community about ACE and available ACE resources, give tips on how to use ACE more effectively, and explain how Riverace can help you make the most of this powerful toolkit.

About Us

Riverace Corporation is the premier support service provider for the ACE toolkit worldwide. Steve Huston, Riverace's President/CEO and founder, has over 20 years' experience developing network protocols and applications. He has coauthored three books on ACE's design and usage and is considered an expert by ACE users around the world. Riverace has been focused on providing world-class technical support and consulting services for ACE since 1997.