Re: Efficient UNO component linkage & GC ...

On 01/16/2014 09:11 AM, Stephan Bergmann wrote:
> On 12/19/2013 10:51 AM, Stephan Bergmann wrote:
> > * for implementations of single-instance services/singletons, we can:
> >
> > ** either stick with the recently introduced prefix="direct" feature,
> > where the service manager obtains a factory for them; any instantiated
> > object instances will continue to be disposed well ahead of exit via
> > disposing the ComponentContext in desktop::Desktop::DeInit
> > (desktop/source/app/app.cxx)
> >
> > ** or also use the constructor="..." feature, in which case the
> > individual constructor functions would need to hold a single instance,
> > which could postpone that instance's destruction to atexit, with all
> > dreaded consequences (an option might be to hold the single instance
> > weakly)
> >
> > ** or use some <implementation single-instance="true" flag in .component
> > XML and implement the logic of holding a single instance in the service
> > manager, which would dispose them when it gets disposed well ahead of
> > exit
>
> Update:  "True singletons" (i.e., implementations for which a .component
> file lists a <singleton ...>) are always disposed when the component
> context is disposed (see how ComponentContext::disposing,
> cppuhelper/source/component_context.cxx, "dispose[s] all context
> objects" and how cppuhelper::ServiceManager::addSingletonContextEntries,
> cppuhelper/source/servicemanager.cxx, registers all those "true
> singletons" at the component context upon bootstrap).  That makes the
> third option above less attractive, as it would cause double dispose of
> them, once from the service manager and once from the component context
> (not that it would typically be harmful to do a double dispose on a UNO
> object, but still).
>
> And given that "false singletons" (i.e., services that are implemented
> with single-instance factories) are a misfeature and should arguably be
> replaced by "true singletons," I think I see a way out.
>
> Let me experiment a little and stay tuned...

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.

Stephan