Manager for ACE library services and singleton cleanup.
The ACE_Object_Manager manages cleanup of objects, typically singletons, at program termination. In addition to managing the cleanup of the ACE library, it provides an interface for application to register objects to be cleaned up. This class also shuts down ACE library services, so that they can reclaim their storage, at program termination. It works by creating a static instance whose destructor gets called along with those of all other static objects. Hooks are provided for application code to register objects and arrays for cleanup, e.g., destruction. The order of such cleanup calls is in the reverse order of registration, i.e., that last object/array to register gets cleaned up first. The ACE_Object_Manager API includes ACE_Managed_Object. That class is contained in a separate file because it is a template class, and some compilers require that template and non-template class definitions appear in separate files. Please see ace/Managed_Object.h for a description of that part of the API. In summary, ACE_Managed_Object provides two adapters, the ACE_Cleanup_Adapter and ACE_Managed_Object template classes for adapting objects of any type to be easily managed by the ACE_Object_Manager. There are several mechanisms for adapting objects and arrays for cleanup at program termination, in roughly increasing order of ease-of-use: 1) Derive the object's class from ACE_Cleanup. 2) Allow the ACE_Object_Manager to both dynamically allocate and deallocate the object. 3) Provide an <ACE_CLEANUP_FUNC> cleanup hook for the object or array. 4) Allow the ACE_Object_Manager to both preallocate the object or array, either statically in global data or dynamically on the heap, when its singleton instance is construction.
There are also several mechanisms for registering objects and arrays for cleanup. In decreasing order of flexibility and complexity (with the exception of the last mechanism):
1) ACE_Object_Manager::at_exit (void *object, ACE_CLEANUP_FUNC cleanup_hook, void *param); can be used to register any object or array for any cleanup activity at program termination. 2) ACE_Object_Manager::at_exit (ACE_Cleanup *object, void *param = 0); can be used to register an ACE_Cleanup object for any cleanup activity at program termination. The final mechanism is not general purpose, but can only be used to allocate objects and arrays at program startup: 3) ACE_Managed_Object::get_preallocated_object (ACE_Object_Manager::Preallocated_Object id); and ACE_Managed_Object::get_preallocated_array (ACE_Object_Manager::Preallocated_Array id); can only be used to allocate objects at program startup, either in global data or on the heap (selected at compile time). These are intended to replace static locks, etc. Instead of creating a static ACE_Object_Manager instance, one can alternatively be created on the stack of the main program thread. It is created just after entry to ::main (int, char *[]), and before any existing code in that function is executed. To enable this alternative, add #define ACE_HAS_NONSTATIC_OBJECT_MANAGER before including the platform specific config-* file in ace/config.h prior to building the ACE library and your applications. This #define is enabled in some config files that are supplied with ACE.
To ensure a static object manager is used, #undef ACE_HAS_NONSTATIC_OBJECT_MANAGER after including the platform specific config-* file. Note that the ACE_Object_Manager must be created before any threads are spawned by the program. If ACE_HAS_NONSTATIC_OBJECT_MANAGER is not #defined, the ACE library creates a static, singleton ACE_Object_Manager instance. The instance is placed in global program data, and constructed via a static object constructor. If ACE_HAS_NONSTATIC_OBJECT_MANAGER is #defined, the ACE_Object_Manager instance is created on the stack of the main program thread, as noted above.
With ACE_HAS_NONSTATIC_OBJECT_MANAGER enabled, the ACE library has no static objects that require destruction. However, there are two drawbacks to using it: 1) main (int, char *[]) must be declared with arguments, even if they're not used. All of ACE is converted to this, so just applications have to be concerned with it. 2) If there any static objects that depend on those that are cleaned up by the Object_Manager, they'll get cleaned up too late. The ACE tests do not violate this requirement. However, applications may have trouble with it. NOTE on the use of <::exit> -- <::exit> does not destroy automatic objects. Therefore, if ACE_HAS_NONSTATIC_OBJECT_MANAGER is enabled, the ACE_Object_Manager instance will not be destroyed if <::exit> is called! However, <ACE_OS::exit> will properly destroy the ACE_Object_Manager. It is highly recommended that <ACE_OS::exit> be used instead of <::exit>.
However, <::exit> and <ACE_OS::exit> are tricky to use properly, especially in multithread programs. It is much safer to throw an exception (or simulate that effect) that will be caught by <main> instead of calling exit. Then, <main> can perform any necessary application-specific cleanup and return the status value. In addition, it's usually best to avoid calling <::exit> and <ACE_OS::exit> from threads other than the main thread. Thanks to Jeff Greif jmg@t.nosp@m.rivi.nosp@m.da.co.nosp@m.m for pointing out that <::exit> doesn't destroy automatic objects, and for developing the recommendations in this paragraph.
Instead of creating a static ACE_Object_Manager, or letting ACE create it on the stack of <main> for you, another alternative is to #define ACE_DOESNT_INSTANTIATE_NONSTATIC_OBJECT_MANAGER. With that #define, the application must create the ACE_Object_Manager. The recommended way is to call <ACE::init> at the start of the program, and call <ACE::fini> at the end. Alternatively, the application could explicity construct an ACE_Object_Manager.