Re: Efficient UNO component linkage & GC ...

On 01/16/2014 06:52 PM, Stephan Bergmann wrote:
> So the way out is to distinguish singleton implementations (whose XML
> description lists at least one <singleton ...>) from normal ones (whose
> XML description does not list any <singleton ...>s), and let the service
> manager keep track to only create a single instance of those.
>
> And for those "false singletons" that are normal implementations by the
> preceding definition but use a single-instance factory, turn them into
> singleton implementations (typically by deprecating an existing UNOIDL
> service and introducing a superseding UNOIDL singleton), and, voila, you
> can convert them to use constructor functions without further ado.
>
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=997d21183322a0a94b96868073808841d2773902>
> "Support for singleton constructor functions" implements the necessary
> machinery in the service manager, and
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=997d21183322a0a94b96868073808841d2773902>
> "Introduce com.sun.star.frame.theGlobalEventBroadcaster singleton" and
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=3557c07899e363a9b7e1cceca632ad9112d039a2>
> "Revert 'Revert 'sfx: Use constructor feature for
> SfxGlobalEvents_Impl''" demonstrate how to apply it to
> SfxGlobaleEvent_Impl.

Bummer.  Where was my brains?  This of course also requires 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=d7a397ca101999a2910c9087d708e0a8c0ea4c2e> 
"Constructor functions for singletons still need to pass out single 
instances":

> ...as they are not only called from the service manager (which takes care of
> singleton constructor functions since 997d21183322a0a94b96868073808841d2773902
> "Support for singleton constructor functions") but potentially also directly
> from cppumaker-generated code (which is the raison d'être for constructor
> functions, after all).
>
> However, this change:
> * postpones the instance's destruction to atexit, with all dreaded consequences;
>   lets see how that pans out.
> * makes it questionable whether the service manager holding references of these
>   singletons (introduced in 997d21183322a0a94b96868073808841d2773902) is
>   necessary after all; lets revisit that in another commit.

Stephan