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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
