Since COM objects can be accessed from outside the Lisp world, possibly from a different application, their lifetimes are controlled more carefully than those of normal Lisp objects. The diagram below shows the lifecycle of a typical COM object.
Figure 1.2 The lifecyle of a COM object
Each COM object goes through the following stages.
In the first stage, the object is created by a call to
make-instance
, either by a class factory (see Class factories) or explicitly by the application. The normal CLOS initialization mechanisms such as
initialize-instance
can be used to initialize the object. During this stage, the object is known only to Lisp and can be garbage collected if the next stage is not reached.
At some point, the server makes the first COM interface pointer for the object by invoking the COM method
query-interface
, either automatically in the class factory or explicitly using by using macros such as query-object-interface or call-com-object. When this happens, the object's reference count will become 1 and the object will be stored in the COM runtime system. In addition, the generic function com-object-initialize is called to allow class-specific COM initialization to be done.
In this stage, the object is used via its COM interface pointers by a client or directly by Lisp code in the server. Several COM interface pointers might be created and each one contributes to the overall reference count of the object.
This stage is entered when the reference count is decremented to zero, which is triggered by all the COM interface pointers being released by their clients. The generic function com-object-destructor is called to allow class-specific COM cleanups and the object is removed from the COM runtime system. From now on, the object is not known to COM world.
The final stage of an object's lifecyle is the normal Lisp garbage collection process, which removes the object from memory when there are no more references to it.